Hi Thorsten,
In these days, I used the methods of QueryPerformanceFrequency and
QueryPerformanceCounter to test the seconds spent by the drawVCLBitmapEx
method (maybe the Intel VTune is the better tool).
The result is not exciting. It spends more time for scaled bitmap than
before. I think the reason is that the time used by the AcquireReadAccess and
Scale methods to scale the bitmap is too long, so the whole time to scale and
draw the smaller bitmap is longer than just to draw the original bitmap.
Scaling the bitmap spends 2/3 of the whole time.
So, what I did before is not a good result, I think. As you said, we can
scale the bitmap when decoding it from the file. But maybe we should use the
original pixels to do something (for example, image segmentation etc.) in some
fields. In this instance, it isn't good too.
I don't know how to resolve this issue proposed by my customer. Can you
give me more suggestions?
Thanks and Regards,
2008-11-18
sunyinan
发件人： Thorsten Behrens
发送时间： 2008-11-15 03:26:16
收件人： [email protected]
抄送： sunyinan; [EMAIL PROTECTED]
主题： Re: [graphics-dev] [Impress] Information about improvingperformance
On Fri, Nov 14, 2008 at 11:02:37AM +0800, sunyinan wrote:
> One of our customers proposed a issue that pictures with big
> size, such as 2M or more, are inserted in the impress slide, when
> we press F5 to show this slide, it is too slow so that he can not
> accept it.
>
Hi Sunyinan,
interesting - so, another thing to try is surely the presentation
minimizer extension, that scales down the images in the file
already, saving on file size as well.
> Then I tracked the code, I found that the bitmap drawn on the
> screen has the original size from the cache. I thought it might be
> way to improve the performance, so I scale the bitmap to a smaller
> size before drawing it. Even if I have not used some tools to test
> the performance, I think it should be better than before.
>
Oh? So, you're not sure your proposed fix does indeed speed up the
rendering? That, I guess, should be the first thing to verify before
embarking on fixing details...
> The following codes are the difference in the dx_vcltools.cxx.
>
Generally, looks good. If the gdi+-method that renders the bitmap is
indeed the bottleneck, I'd go for your fix, as this is really
nothing to be decided in platform-independent code (as there, the
actual output resolution is not generally known).
Please consider subscribing to the lists you post to, otherwise you
might miss replies going to the list only.
Cheers,
-- Thorsten
