[webkit-qt] GraphicsContext and Canvas

[Yongjun.Zhang at nokia.com]

Hi,

I also think it might be a good idea to use QImage for web images.  Currently we have to convert Qimage to Qpixmap when an image is decoded and ready for painting.  I understand this is better for performance that painting Qpixmap could be hardware accelerated.  However, if we want to enable progressive image decoding, there could be way too many Qimage to Qpixmap conversions because every image data chunk coming from the network triggers that.  Plus, both Qimage and Qpixmap has to be kept in RAM for short period, which increases the peak memory consumption too.

Thanks,

/Yongjun



>-----Original Message-----
>From: webkit-qt-bounces at lists.webkit.org 
>[mailto:webkit-qt-bounces at lists.webkit.org] On Behalf Of ext 
>Antti Koivisto
>Sent: Friday, February 05, 2010 4:17 AM
>To: Knoll Lars (Nokia-D-Qt/Oslo)
>Cc: webkit-qt at lists.webkit.org
>Subject: Re: [webkit-qt] GraphicsContext and Canvas
>
>Hello,
>
>QPixmap is generally a pretty strange abstraction. Depending 
>on context it maps to different backends with hugely varying 
>performance and other characteristics. For example it is 
>probably not good use of scarce texture memory to hold web 
>page image resources, yet that is what happens when using 
>OpenGL graphics system.
>
>QPixmap can currently be accessed from the application main 
>thread only as some backends are not thread safe. This will be 
>a problem in the future. QImage does not have this limitation.
>
>I wish we could get rid of QPixmap entirely in WebKit.
>
>
>  antti
>
>On Thu, Feb 4, 2010 at 9:50 AM, Lars Knoll 
><lars.knoll at nokia.com> wrote:
>> Hi Ariya,
>>
>> great you're looking into this.
>>
>> One thing worth considering is IMO to only use a QImage to 
>render the 
>> canvas content into, and avoid any caching/conversion magic between 
>> images and pixmaps. We don't get any HW acceleration for 
>drawing with 
>> this, but it might still be faster and easier than doing 
>possible conversions back and forth.
>>
>> Cheers,
>> Lars
>>
>> On Thursday 04 February 2010 07:56:50 am Rosenthal Noam (Nokia-D-
>> Qt/RedwoodCity) wrote:
>>> Hi Ariya
>>> First of all, awesome that you're looking into this! I was praying 
>>> for this
>>>  moment :) Second - our canvas implementation is not just 
>slow, it's 
>>> also
>>>  inaccurate. See https://bugs.webkit.org/show_bug.cgi?id=32405.
>>>
>>> About that internal buffer - how would that work with HW 
>acceleration 
>>> and
>>>  memory consumption, also considering  that GraphicsLayer has an 
>>> additional
>>>  intermediate buffer in the form of graphics-view cache?
>>>
>>> Cheers
>>> No'am
>>>
>>>
>>>
>>> ________________________________________
>>> From: webkit-qt-bounces at lists.webkit.org
>>>  [webkit-qt-bounces at lists.webkit.org] On Behalf Of ext Ariya Hidayat
>>>  [ariya.hidayat at gmail.com] Sent: Wednesday, February 03, 2010 10:43 
>>> PM
>>> To: webkit-qt at lists.webkit.org
>>> Subject: [webkit-qt] GraphicsContext and Canvas
>>>
>>> Hello good people,
>>>
>>> Currently Canvas is not performing very well, see 
>>> https://bugs.webkit.org/show_bug.cgi?id=32530 for the 
>details of one 
>>> of the problems. I have a patch for that (attached in the 
>bug, please
>>> review!) by introducing BufferedImage, but that is just a stop-gap 
>>> measure. This is because ImageBuffer still gets created and 
>destroyed 
>>> for every single frame, which causes us to recreate the pixmap for 
>>> the canvas all the time.
>>>
>>> My proposal would be as follows. We change Graphics Context so that 
>>> it has an internal buffer (of ImageBuffer instance). For a graphics 
>>> context that operates on a canvas, we just use its ImageBuffer for 
>>> the painting, with some reference counting so everytime we 
>clear the 
>>> (Buffered)Image instance we don't need to throw the pixmap 
>again and 
>>> again.
>>>
>>> Bonus: we can get rid of our ImageBufferData.
>>>
>>> Also, this opens further optimization for pixel 
>manipulation (which I 
>>> have planned to do since ages, but then I am a lazy guy :). 
>Currently 
>>> getting or setting a pixel from our canvas converts the 
>pixmap to an 
>>> image and later back again to the pixmap (expensive on non-raster 
>>> graphics systems). If we can keep both the pixmap and image 
>>> ourselves, we might do some heuristic caching and optimization. For 
>>> example, usually pixel manipulations are not interleaved with 
>>> vector/path fill/stroke etc. This allows us to keep either 
>the pixmap 
>>> format or the image format as long as we need it and avoid constant 
>>> conversion between them.
>>>
>>> I'l try to give it a shot in the next few weeks. Ideas and 
>feedbacks 
>>> are warmly welcomed.
>>>
>>> Thank you!
>>>
>>> Regards,
>>>
>>>
>>> --
>>> Ariya Hidayat
>>> http://www.linkedin.com/in/ariyahidayat
>>> _______________________________________________
>>> webkit-qt mailing list
>>> webkit-qt at lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
>>> _______________________________________________
>>> webkit-qt mailing list
>>> webkit-qt at lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
>>>
>> _______________________________________________
>> webkit-qt mailing list
>> webkit-qt at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
>>
>_______________________________________________
>webkit-qt mailing list
>webkit-qt at lists.webkit.org
>http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
>