Re: Some clarifications needed on rendering management
On Fri, Sep 5, 2008 at 6:13 AM, Brett Wilson [EMAIL PROTECTED] wrote: On Sep 3, 9:56 pm, Mark Wang [EMAIL PROTECTED] wrote: The render processes paint to offscreen DCs. Each render process (ie, tab) retains its own DC. This isn't true. Each render process paints into a new DC every time we paint, and it gets sent to the browser process. Handles to the (offscreen) bitmap are passed in the IPC messages. (But not the actual bitmaps themselves.) The main browser process takes care of presenting those bitmaps in turn, on screen. The browser process keeps a copy of the contents of the foreground tabs, and maybe a few background ones as well in a cache. It gets paint and scroll events from the renderer, and updates this bitmap with the new information (for example, a paint might only be a small portion of the screen, and only this changed area will be sent by the renderer to the browser). This bitmap is a device dependent bitmap on the video card so scrolling and copying it to the screen is quick. minor correction: not a device dependent bitmap anymore. it is a device independent bitmap now. DDBs are problematic in that they take up space in the memory alloted to the desktop, and that can have a very low limit. it can be very problematic for the entire desktop if that limit is reached or if enough of it is used such that other allocations fail (it is typical for apps to ask for large transcient DDBs). so it is not a good idea to keep DDBs hanging around for long. -darin Thumbnail generation is done in RenderView::CaptureThumbnail in response to a message: an image is resized within the render process and the (actual) thumbnail is IPCed to the main process for the most visited welcome screen. Yes Also for the tab dragging, in the browser process HWNDPhotobooth::PaintScreenshotIntoCanvas takes the HWND of the tab being dragged, captures it, (which is then downsampled in SkBitmap::buildMipMap) and then paints it into a layered window which is what is shown during dragging. Yup. Brett --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
Re: Compiling with Visual Studio 2008
Now i have only 1 error but it is not in a chrome's file
std::_Tmap_traits_Kty,_Ty,_Pr,_Alloc,_Mfl::_Tmap_traits(_Pr,_Alloc)' :
cannot convert parameter 2 from 'PrivateHookAllocatorT' to
'PrivateHookAllocatorT'
file C:\Program Files\Microsoft Visual Studio 9.0\VC\include
\xtree
_Tree_nod(const key_compare _Parg,allocator_type _Al):_Traits(_Parg,
_Al),_Alnod(_Al)
error here { // construct traits from _Parg and
allocator from _Al
}
Any suggestion??
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Chromium-dev group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---
Re: Security concern with URL bar
Thanks for bring up this issue. We're tracking this at: http://code.google.com/p/chromium/issues/detail?id=1647 Adam On Sat, Sep 6, 2008 at 8:27 PM, John Steenbruggen [EMAIL PROTECTED] wrote: The URL bar completion and search feature of the Chrome causes the full typed URL to be send to Google's servers. This feature occurs if the URL is typed or even pasted in. It occurs even if the URL starts with HTTPS. It even includes all of the GET parameters. The URL data is sent to Google's servers over an HTTP connection. Hopefully the issue is already clear, but this means that information like usernames, passwords, account numbers, session IDs, etc that were never meant to be in the clear are now being sent across the internet for all to read. With everyone doing deep packet inspection these days, it likely means the data is not only exposed, but stored and searchable. Nobody expects their search strings to be secure. But one of the key features of HTTPS is that the URL itself is not exposed. This feature is putting Chrome users at jeopardy. Here are some suggestions to reduce the vulnerability: 1) Don't provide this functionality if the URL starts with HTTPS (Best complete solution) 3) Don't send GET parameters (partial solution, some sides do use directory names as data parameters) 2) If the URL starts with HTTPS, send the URL data to Google using HTTPS (Do users really trust Google with their usernames, passwords, account numbers, etc when Google has no need for them?) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
Re: OpenGL and rendering to texture
3D rendering has come up. It is very challenging because or our architecture and the sandbox. The renderer can't have a HWND on the screen, for example, and OpenGL can't share rendering contexts between processes (on or off screen). (I heard the next version of DirectX might, but I'm not sure.) This means that we'd have to copy out of the screenbuffer to cross the process boundary, which would negate any benefit. Brett --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
Re: Re: OpenGL and rendering to texture
--~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
