[webkit-help] Capture rendering buffer (windows)
Chris Hatko
chatko at gmail.com
Tue Aug 3 07:28:22 PDT 2010
Hi Vizshala,
I don't invalidate the entire backingstore. You could just invalidate the
plugin area(s) by adding them to the dirty area.. I use the backingstore as
is, by using an interface in WebViewPrivate to gain access to the
backingstore "backingStore" bitmap. Note that if your window is hidden the
backingstore may be deleted. I had to hack some of the webkit code to
prevent this from happening.
Chris
On Mon, Aug 2, 2010 at 11:20 PM, vizshala <vizshala at gmail.com> wrote:
> Hi chris,
>
> I also noticed that in windowless mode ( transparent or opaque ), the CPU
> comsumption is more than window mode.
> In my machine with amd phenom quad-core 2.5GHz, playing youtube video in
> the window mode will comsume about 5% CPU resource while the windowless mode
> will double it to about 10%.
>
> At first I tried to capture the web view in windowless mode at the frame
> rate of 30 per second. The steps I took are as follows:
>
> 1. invalidate the backingstore :
> according to the NPAPI rule, the windowless plugin will call
> NPN_InvalidateRect to notify the browser that the plugin area is dirty.
> After PluginView got notified, it will invalidate the rect, finally WebView
> will add this rect to dirty region. So I use a UI Delegate to receive the
> dirty rect.
>
> 2. fetch the backingstore handle
>
> 3. copy bits by bitblt
>
> But the cpu usage is about 15%, performance is not acceptable. After some
> search, I found that the step1 is the performance hit. I think this is due
> to the updateBackingStore will go through the layout again.
>
> Is it possible to improve the performance? thx
>
> Regards,
> vizshala at gmail.com
>
>
> 2010/7/22 Chris Hatko <chatko at gmail.com>
>
> Hey,
>>
>> I'm still not fully done. I've implemented a solution which forces
>> every flash plugin to run in windowless mode (force WMODE param).
>> Doing this gives the render control over painting and as long as i
>> invalidate the plugin area, and replicate some of the WM_PAINT
>> functionality the m_backingStoreBitmap contains the flash drawing.
>> (even when the flash window is hidden)
>>
>> I think a better solution would be to use WM_PAINT hijacking in
>> PluginViewWin.cpp and insert your own HDC. ( note that in windowed
>> mode, all drawing is done by the plugin app through
>> PluginView::wndProc). I'm going to trail a solution this week which
>> does this. It should also support other plugins (reader, quicktime
>> etc). I'll likely post my findings to the group.
>>
>> Chris
>>
>>
>>
>> On Thu, Jul 22, 2010 at 9:26 AM, vizshala <vizshala at gmail.com> wrote:
>> > hi Chris,
>> >
>> > In your original post, you mentioned that it may be possible to let
>> flash
>> > paint directly into the m_backingStoreBitmap or the dc we created. Did
>> you
>> > use api hijacking like the webkit did in pluginview or something else?
>> >
>> > thx
>> >
>> > 2010/7/13 Chris Hatko <chatko at gmail.com>
>> >>
>> >> Thanks Alex,
>> >>
>> >> I tried using paintDocumentRectToContext, but I was asking for the
>> >> paint 30/sec and found that providing a rectangle for the entire
>> >> window was too slow. I've made some progress with my original method
>> >> which only invalidates the flash/plugin areas and uses the
>> >> backingstore bitmap as the 30/sec snapshot. Below is some code I found
>> >> to search for plugin areas. I Hope it helps someone ...
>> >>
>> >> // get the plugin (flash) areas and invalidate them
>> >> IntRect pluginArea;
>> >>
>> >> for (Frame* frame = (this->m_page)->mainFrame(); frame; frame =
>> >> frame->tree()->traverseNext())
>> >> {
>> >> FrameView* view = frame->view();
>> >> if (!view)
>> >> return 0;
>> >>
>> >> const HashSet<RefPtr<Widget> >* children =
>> view->children();
>> >> ASSERT(children);
>> >>
>> >> HashSet<RefPtr<Widget> >::const_iterator end =
>> >> children->end();
>> >> for (HashSet<RefPtr<Widget> >::const_iterator it =
>> >> children->begin(); it != end; ++it)
>> >> {
>> >> Widget* widget = (*it).get();
>> >> if (widget->isPluginView()) // works for flash at
>> least
>> >> {
>> >> pluginArea =
>> >> (static_cast<PluginView*>(widget))->windowClipRect();
>> >> this->addToDirtyRegion(pluginArea);
>> >> }
>> >> }
>> >> }
>> >>
>> >>
>> >> One item i have noticed and that I've wasted many hours debugging is
>> >> that the latest Flash (10.1) doesn't render at full speed when it is
>> >> in a hidden window. I'll send another question to the group detailing
>> >> this.
>> >>
>> >> Thanks,
>> >>
>> >> Chris
>> >>
>> >>
>> >> On Mon, Jul 12, 2010 at 8:34 AM, Alexander Shulgin
>> >> <alexander.shulgin at yessoftware.com> wrote:
>> >> > On 09.07.2010 22:18, Chris Hatko wrote:
>> >> >>
>> >> >> Hi,
>> >> >>
>> >> >> My goal is to get the cario webkit port to render to a buffer
>> instead
>> >> >> of a window (i'll be making the window invisible), with as little
>> >> >> change to the port source as possible.
>> >> >
>> >> > I'm using IWebFramePrivate::paintDocumentRectToContext(RECT, HDC) for
>> >> > this.
>> >> > It works with pretty reasonable results and w/o the need to modify
>> the
>> >> > source code.
>> >> >
>> >> > --
>> >> > Alex
>> >> > _______________________________________________
>> >> > webkit-help mailing list
>> >> > webkit-help at lists.webkit.org
>> >> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-help
>> >> >
>> >> _______________________________________________
>> >> webkit-help mailing list
>> >> webkit-help at lists.webkit.org
>> >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-help
>> >
>> >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-help/attachments/20100803/d0388818/attachment.html>
More information about the webkit-help
mailing list