Why is drawing to alpha channel pics so slow?

Same netbook booting into Win7 and Ubuntu. Real Studio 2012r2.1 and Xojo 2013r2, run via remote debugger, but built apps see similar performance differences. This is for a 200 x 32 alpha channel (new style) picture, p:

if p <> nil then g = p.Graphics g.ClearRect(0, 0, p.Width, p.Height) end if
500-ish iterations of this on Linux average 0.5 ms. 500 iterations on Win7 average 20 ms. Any good reason to expect this? I’m seeing similar drawing sluggishness with other Fill operations, but this is one I could easily isolate for the Profiler. Mac performance is consistent with speed difference between by MBP and the netbook.

Ok, let’s burn my obvious first option before passing the token to Xojo to them say something about how they implemented not having proper buffering, etc.: Are you using the latest video driver for this machine / Win7 ?

Video driver should have nothing to do with it. It’s an in-memory picture. I’m guessing that I could write a plugin function to fill the buffer to transparent pixels in much less than 1ms. But this is interesting because I could isolate and time it easily.

Maybe seems weird and probably not related, but Interestingly I wrote a chart program for another environment around 12 years ago, in memory, and I don’t know why their plot routines were tied to the video card. If I changed the video card to a old 256 color card, the bmp I got was 256 colors regardless of myself setting the in memory mode to 64K colors. So, weird things sometimes can happen under windows depending on how the graph routines are tied to the graph system.

Have fun with this. Probably you will make it better than the current native. Let’s wait for Joe’s opinion.

My wild guess is extraneous copying. I haven’t dug in yet, but I don’t remember seeing this kind of performance penalty with touching picture pixels from a plugin.

Having a peek at our Graphics.ClearRect code I can see why this could be a slower operation, however other drawing routines should be just as fast as GDI on an alpha channel picture, with the exception of string drawing (we use GDI+ text rendering exclusively for alpha channel pictures and GDI+ text rendering is quite a bit slower than GDI text rendering).

Ok, that might explain most of the relative Win7 slowness I’m seeing. Lots of strings to alpha channel pictures. Would a feature request to have a way to turn off GDI+ text rendering off make sense?

You could but this means some spectacular changes. :slight_smile: Alpha channel pictures are created using GDI+, which means interop’ing with GDI is tremendously expensive (in other words you can’t really interop in that direction, but rather hack GDI drawing into a GDI+ graphics context). Using GDI+ on a GDI graphics context is much easier (i.e. supported and not a hack), so we’d have to start creating alpha channel pictures in GDI, which I do not think is efficient except for the annoying case of string drawing.

Compounded over my listbox replacement, it’s the difference between around 80ms to refresh an area from scratch on Ubuntu to around 500ms for a similar refresh under Windows 7. While scrolling and updating, that’s the difference between snappy and quite sluggish. I’m using cell buffers so local scrolls are super quick. The alpha channel is really important for listbox picture or texture background. It’s probably the worst test case imaginable. Allocating an old style picture, drawing to it’s mask, and blitting on the new style picture is even worse :-).

Well, at least I get what’s going on here. Hmmmm.

The GDI+ text rendering is something you really want though
It doesn’t look nearly as nice with GDI