[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]
RE: [XaraXtreme-dev] OSRenderRegion::DrawTransformedBitmap
- From: Alex Bligh <alex@xxxxxxxxxxx>
- Date: Thu, 27 Apr 2006 11:24:59 +0100
- Subject: RE: [XaraXtreme-dev] OSRenderRegion::DrawTransformedBitmap
In Xtreme we experimented with using GRenderRegions in the bitmap
gallery to improve the quality of the thumbnails. (The quality of the
thumbnails in the bitmap gallery using OSRenderRegion is truly appalling
- sticks out like a sore thumb to me...) This change was removed before
release of Xtreme because it was slower than the OSRenderRegion
equivalent but maybe that's not true under wxWidgets.
We did this simply by changing BitmapSGallery::CreateRenderRegion to
call CreateGRenderRegion instead of CreateOSRenderRegion. (And similar
change to DestroyRenderRegion.)
That might not suit because of the text rendering problem you mention
but it might be educational to try it. Maybe it simpler to fix system
text rendering in GRenderRegion than attempting the things you are
Well the two charcter change to those routines made the bitmaps plot, but
not the text of the resource icons.
It does indeed run very slowly, I think because it's trying to background
redraw the gallery or something - certainly doesn't look like it is
However, fixing up the text is not a simple exercize. The way
DrawFixedSystemText seems to work in GRenderRegion is it plots it to the
MSW equivalent of a memory DC. This then gets into a kernel bitmap, and is
plotted as a bitmap using the normal GDraw routines. But this itself is not
particularly simple, because the wxMemoryDC will be in wxImage format, and
I am left with the former problem but in reverse, i.e. how to get the
wxImage into a KernelBitmap format. So I've got just as much odd code to
That's quite aside from the fact that inevitably the galleries will end
up looking slightly different, which I'm trying to avoid. And it means
large areas are painted relatively inefficiently.
So ideally I'd like to keep them drawn by OSRenderRegion, but with the
thumbnail resampled using GDraw (somehow). I suppose I /could/ just
call the GDraw primatives directly (i.e. maintain my own GDraw context).
I have a feeling something else used to do this precisely in order to
rescale bitmaps. Perhaps it was my bitmap effects stuff or the tracer.
It /shouldn't/ be necessary to cache the thumbnails given we are currently
doing a StretchBlit every time - what's proposed should be no worse
that StretchBlit (except, arguably, the single copy of the shrunk down
preview bitmap). Though obviously we can cache them if need be. In some
cases though (e.g. 1bpp bitmaps) the cached image may be larger than the