[Development] Qt 4.8 and possibly 5: QVGPaintEngine implement a cache manager for vgpaths.
Nikolaos Korkakakis
korkakak at gmail.com
Fri Feb 24 10:22:06 CET 2012
Hi Gunnar,
On Fri, Feb 24, 2012 at 8:17 AM, <gunnar.sletta at nokia.com> wrote:
>> I am interested in implementing a cache manager for VGPath(s) for the
>> openvg sybsystem, and I am thinking after a bit of reading the proper
>> way to do that,is by creating an LRU (in similar fashion as with
>> QVGImagePool).
>>
>> Since paths are more prone to alterations (to my understanding at
>> least) am looking a way to quickly destroy the vgpath associated, and
>> the only viable way is by <ahem>adding some extra logic in the
>> QVectorPath and QPainterPath to handle the invalidations (ideally it
>> would be just check if a pointer is non-null and then free).
>
> QVectorPath already has this logic built in, so no hacking required.
Nice thanks, I will look more into it.
>The OpenGL 2 paint engine uses this mechanism to store triangulated polygons. In practice we found that it doesn't help as often as we like because users very rarely store their QPainterPath's >between one paintEvent() and the next
In my opinion this has nothing to do with the user. The thing is to
provide the user with a framework for better or worse. Of course there
might be some programming methodologies that can hinder the
performance, but there should be others to help boost it.
>and creating a cache based on the content of the data-array is too high a price to pay.
>
so true.
> You should also know that there is no longer any QVGPaintEngine in Qt 5.
>
That came as as shock! Since the qtdd11 where I talked with various
guys I was left with the impression, that openvg will still be around
for widget accel, (but will not support the latest and greatest new
qt5 features). I also don't keep track of qtbase but there used to be
a src/openvg dir I swear :P.
qtbase/ $ git rev-list HEAD -- src/openvg
4ece3fc24e4a2855cfb75a5da0dc2197a87092cd
ok now I see it
> cheers,
> Gunnar
>
>
Thanks for answering, I will start working on option number one.
BR,
N.
More information about the Development
mailing list