[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]
Re: [XaraXtreme-dev] OSRenderRegion::DrawTransformedBitmap
- From: Phil Martin <phil@xxxxxxxx>
- Date: Thu, 27 Apr 2006 11:42:09 +0100
- Subject: Re: [XaraXtreme-dev] OSRenderRegion::DrawTransformedBitmap
Alex Bligh wrote:
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
GRenderRegions do not background render in themselves - background
rendering is handled by the View classes which shoudl not be involved here.
Related: I've noticed that rectangle merging appears to be disabled on a
document view when the bitmap gallery is opened and dragged around. But
only while the gallery window falls partly inside, partly outside the
view. As soon as the gallery window falls entirely within the view
rect, region merging seems to start up again.
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,
plotted as a bitmap using the normal GDraw routines. But this itself
particularly simple, because the wxMemoryDC will be in wxImage format,
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
No scaling or resampling involved this time... ???
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.
They shouldn't look /that/ different if system text rendering is working
properly in GRenderRegion.
I realise there are reasons why maybe this stuff has to be tackled in
the long run for other areas of the program - just pointing out possible
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
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