-
Notifications
You must be signed in to change notification settings - Fork 34
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
Conversation
Fixed arrange problems when intializing Added close method
Wow, great work. I will be merging this after I update CefSharp to wrap the newest version of CEF. Thanks. |
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. |
Ah, yeah I am working on redoing the JS evaluation to use V8Context rather than the existing V8Task stuff. |
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. |
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. |
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 |
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. 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. |
Wow, did you make these graphs? I'm in favor of sticking with the I still haven't been able to figure out how to rework the synchronous --Anthony On , joaompneves
|
Yeah. I used the Perforator from WPF Performance Suite and Process Explorer. I see some examples here: Probably you already knew it. |
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.