Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 21 Apr 2000
Offline Last Active Today, 03:46 PM

Topics I've Started

Weird corruption when drawing text with DrawString

07 March 2014 - 10:18 AM

OK, so I'm experiencing the weirdest problem.  I'm drawing some text and it's showing up corrupted:

Attached File  Corrupted.png   15.71KB   3 downloads


So, as you can see, the image on the left shows the corrupted text in Windows 8.1 and on the right the actual text is being rendered correctly in Windows 7.  


The corruption only happens when I have the CompositingMode set to SourceCopy and the TextRenderingHint set to SingleBitPerPixel (with and without GridFit).  I require SourceCopy as my compositing mode because I need to write to the alpha channel of the bitmap instead of blending the alpha with the bitmap contents.


The code that draws this text is incredibly simple, so I am at a loss as to why this is happening.  


Anyone else run into this problem?  Know of a way around it?


Here's the code that I used to repro the error:

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Drawing.Drawing2D;
using System.Drawing.Imaging;
using System.Drawing.Text;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Windows.Forms;

namespace TestFontAntiAlisBug
    public partial class Form1 : Form
        private Bitmap _image;
        private Font _font;

        protected override void OnLoad(EventArgs e)

            _font = new Font("Andalus", 48.0f, GraphicsUnit.Point);
            _image = new Bitmap(256, 256, PixelFormat.Format32bppArgb);

            using (Graphics g = Graphics.FromImage(_image))
                g.CompositingMode = CompositingMode.SourceCopy;
                g.CompositingQuality = CompositingQuality.HighQuality;
                g.TextRenderingHint = TextRenderingHint.SingleBitPerPixelGridFit;

                using (Brush brush = new SolidBrush(Color.White))
                    g.DrawString("Are you corrupted?", _font, brush, new PointF(0, 0));

        protected override void OnPaint(PaintEventArgs e)

            e.Graphics.DrawImage(_image, new Point(0, 0));

        public Form1()

Performance of geometry shaders for sprites instead of batching.

25 September 2012 - 02:16 PM

I haven't really used the Geometry Shader stuff before. I'm old and don't like change. It frightens me.

But, currently with Gorgon I'm recycling a dynamic vertex buffer to display my sprites. Basically if the sprites use the same texture, shader, etc... it adds the sprite to the buffer until it's full or until there's a state change. If the buffer is full, then it's discarded, otherwise more sprites get appended until full. Upon state change or discard, it gets flushed to the render target in one draw primitive call. This seems pretty standard to me, and it's been working quite well for me.

However, I've been giving some thought to using a geometry shader to stream out the sprites. I've done a little reading and it seems that this is an ideal use case for GS. But, apparently there's a few gotcha's with these shaders? Notably, the 1024 32 bit float limit. I understand that the size of data out might an issue as well?

Currently, I'm using a position, color and uv coordinates for my sprites vertices. I suspect I'd need to send all of these, and more besides to shader to meet my needs. So would that cause an issue? I pre-transform my vertices before sending them to the vertex buffer (i.e. no world matrix, I've found this to improve performance), and update the vertex position by the camera and projection matrix in the vertex shader. Will this cause an issue?

Has anyone here used a GS to power a sprite renderer? Did you compare its performance to a batched solution (like the one I presented above)? I'm not able to set up a test project for the time being, so if I could get some feedback, that'd be swell.


File I/O streaming performance.

17 September 2012 - 09:28 AM

I have a Windows application in C++ here that's got a very large file to stream in. The file is ~5GB in size, and currently the code does this:
  • Open file if not already open.
  • Read in a block of data (~9 MB)
  • Copy to volume texture
  • Render
  • Repeat...
The file access is sequential and called at the end of every frame and currently I'm using the CRT file I/O stuff (fopen, fseek, fread, and fclose). And I'm wondering if there's a better way with regard to performance?

Would using memory mapped files be a good idea here? I've read conflicting statements about performance when it comes to reading a file sequentially.

I've considered loading a larger chunk of the file (i.e. multiple volume textures) in one shot, but I'm thinking that it'll hit a bottleneck when it's used up those textures and has to read in the next chunk.

Obviously, I can't read in the entire file (needs to run on 32 bit, that'd kill my process space quickly) and because of the environment I have to use (I really have no choice regarding this) I can't use threading.


Getting spam

28 May 2012 - 07:06 PM

I don't know who to contact about this, or if this is the right forum for this, but I just received a spam message:

nice to meet you
MY dear friend my name is
morein i,m very decent girl
with honest love caring please
i will like be your friend
wirte me back with my mail
so that i will give you my picturesmy
i found your profile here
It's never my desire to remain what I am now,
but struggling to become what am.
pls dont reply me in dis site( website)
reply me in dis email


The user name is morein500

Just letting you guys know.

[SharpDX] Error saving a 2D texture to a stream/file.

08 March 2012 - 09:58 AM

I'm getting an odd exception (HRESULT 0x80004005, and the debug info isn't telling me anything at all) whenever I try and persist a 2D texture to a stream or file. It works if I use a DXGI_FORMAT_R8G8B8A8_UNORM format, but if I use DXGI_FORMAT_B8G8R8X8_UNORM it gives me an error. Internally, SharpDX is using D3DX11SaveTextureToMemory to copy the data into a (what I assume is a) D3D10BLOB. I usually save my files to a FileStream object when sending to disk, but that's failing too. FYI, this is using downlevel feature levels for D3D9 cards and D3D10.1 (no idea if D3D 10.0 or 11.0 works or not).

Is there some known incompatibility with D3DX11SaveTextureToMemory and specific formats?