Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improved control rendering #8

Closed
wants to merge 2 commits into from
Closed

Conversation

joaompneves
Copy link

Improved control rendering using a InteropBitmap instead of a WriteableBitmap. According to my tests and measures this uses a little less CPU and memory but a little more GPU memory - at the end of the day this is better. Also allows changes to the image buffer in other threads other than the UI thread and fixes application dead-locks when running Javascript at the same time of render.
Fixed a problem with arrange when the browser was not initialized which could lead to no image at all.
Added CEF graceful shutdown call.

Fixed arrange problems when intializing
Added close method
@ataranto
Copy link
Owner

Wow, great work. I will be merging this after I update CefSharp to wrap the newest version of CEF. Thanks.

@joaompneves
Copy link
Author

Cool. Btw, I hope that the new CEF version fixes some "pure virtual function call" errors that I have from time to time when executing Javascript through RunScript. I don't know why I keep getting those errors but I know it comes from under the hood (CEF) when executing the exact same script hundreds of times.

@ataranto
Copy link
Owner

Ah, yeah I am working on redoing the JS evaluation to use V8Context rather than the existing V8Task stuff.

ataranto added a commit that referenced this pull request Dec 3, 2011
@ataranto
Copy link
Owner

ataranto commented Dec 3, 2011

i merged this into my cef_update branch, thanks for the great work. note that cef now sends a list of dirty rects rather than one. i would like to look into only invalidating the dirty rects at some point...

as for the javascript progress, i started some work on reimplementing a simple, synchronous api here:

http://code.google.com/p/chromiumembedded/issues/detail?id=444

I am going to look at a more comprehensive wrapping of the JavaScript invocation stuff now.

@ataranto ataranto closed this Dec 3, 2011
@joaompneves
Copy link
Author

Cool.

Since the project is still using .Net 3.5 we cannot take advantage of a bug fix in the Writeable Bitmap in .Net 4.0 ("WriteableBitmap was not respecting dirty rect size. If your dirty region is small compared to the size of the entire WriteableBitmap, you will see CPU improvement." in http://blogs.msdn.com/b/wpf3d/archive/2009/10/20/what-s-new-in-graphics-for-4-0-beta-2.aspx) that's why i moved to the InteropBitmap. If you think it's easy to move up on the .Net framework version I can work on improving the rendering using the Writeable Bitmap.

@ataranto
Copy link
Owner

ataranto commented Dec 3, 2011

I'd known about that bug but wasn't sure that it had been fixed. I'm not too familiar with the differences between InteropBitmap and WriteableBitmap. Can we somehow use InteropBitmap and only redraw dirty rects?

If not, let's move back to WriteableBitmap and have a soft requirement on 4.0 (as in, if you have 4.0 great, drawing will be fast, if you want to stay with 3.5, drawing will be slow but it will still work).

My main concern with writeable bitmap was that it was causing the synchronous JavaScript evaluation to timeout or fail.

--Anthony

@joaompneves
Copy link
Author

The thing about the Writeable Bitmap is that it allows you to specify the dirty region which is copied to the video memory buffer whereas the Interop Bitmap always copies the entire bitmap.
But the reality is much different as some tests, I've done, state:

https://docs.google.com/document/pub?id=1yRbEMmCd1A3DzG81JpJYuJhi3G8L_IqO_JD5BGfeXgI

So I think for now the Interop Bitmap (on the .Net 3.5) is the best choice.

@ataranto
Copy link
Owner

ataranto commented Dec 3, 2011

Wow, did you make these graphs? I'm in favor of sticking with the
InteropBitmap stuff for now. Again, great work.

I still haven't been able to figure out how to rework the synchronous
JavaScript evaluation to the new V8Context API. I have to somehow run the
JavaScript on the CEF UI thread (TID_UI), but I can't figure out how to use
the cef_runnable.h API to block the calling thread and post the task to the
appropriate CEF thread successfully. I will keep poking at it though.

--Anthony

On , joaompneves
reply@reply.github.com
wrote:

The thing about the Writeable Bitmap is that it allows you to specify the
dirty region which is copied to the video memory buffer whereas the
Interop Bitmap always copies the entire bitmap.

But the reality is much different as some tests, I've done, state:

https://docs.google.com/document/pub?id=1yRbEMmCd1A3DzG81JpJYuJhi3G8L_IqO_JD5BGfeXgI

So I think for now the Interop Bitmap (on the .Net 3.5) is the best
choice.


Reply to this email directly or view it on GitHub:

#8 (comment)

@joaompneves
Copy link
Author

Yeah. I used the Perforator from WPF Performance Suite and Process Explorer.

I see some examples here:
http://chromiumembedded.googlecode.com/svn-history/r389/wiki/JavaScriptIntegration.wiki

Probably you already knew it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants