Re: [chromium-dev] Re: test_shell performance is bad compared to Chromium
On Thu, Nov 5, 2009 at 3:34 PM, Alexander Teinum atei...@gmail.com wrote: I want to make it clear, and it might be obvious by now, but test_shell isn't interesting to me. I just want the fastest browser engine that I can get. What makes Chromium different than WebKitGTK+ for my project, is that Chromium renders the GTK stuff correctly with CSS transformations. It's also snappier. Conceptually Chrome is a bunch of layers, from top to bottom 1) chrome+ui junk 2) multiprocess rendering 3) webkit API 4) webkit Test shell covers layer 3 and down. Unfortunately, all the performance you like is in layer 2. We don't have a simple place to cut for that; however, since Chrome and test_shell are both just clients of the WebKit API, you could write your own client (like test_shell) and then copy the performant bits out of Chrome. It will require some work, but if it were easy then your job would be boring. :) -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: test_shell performance is bad compared to Chromium
Test shell covers layer 3 and down. Unfortunately, all the performance you like is in layer 2. Thanks for clarifying. I have had some time to think about what you guys have been saying, and I have decided to start out with kiosk mode. At some point in the future I will probably want to remove what I don't need. It will require some work, but if it were easy then your job would be boring. :) I'm getting used to not having a boring job. On Tue, Nov 10, 2009 at 7:26 PM, Evan Martin e...@chromium.org wrote: On Thu, Nov 5, 2009 at 3:34 PM, Alexander Teinum atei...@gmail.com wrote: I want to make it clear, and it might be obvious by now, but test_shell isn't interesting to me. I just want the fastest browser engine that I can get. What makes Chromium different than WebKitGTK+ for my project, is that Chromium renders the GTK stuff correctly with CSS transformations. It's also snappier. Conceptually Chrome is a bunch of layers, from top to bottom 1) chrome+ui junk 2) multiprocess rendering 3) webkit API 4) webkit Test shell covers layer 3 and down. Unfortunately, all the performance you like is in layer 2. We don't have a simple place to cut for that; however, since Chrome and test_shell are both just clients of the WebKit API, you could write your own client (like test_shell) and then copy the performant bits out of Chrome. It will require some work, but if it were easy then your job would be boring. :) -- Best regards, Alexander Teinum -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Re: test_shell performance is bad compared to Chromium
I could probably hack it so that it went into fullscreen, and then disable F11, but that's dirty. All the UI stuff from Chromium would still be there, although it would be hidden. Alexander On Thu, Nov 5, 2009 at 10:32 PM, Dirk Pranke dpra...@chromium.org wrote: test_shell being a test shell used mostly for non-interactive testing, we haven't given a lot of concern to its perfomance AFAIK. I'm not even sure how long of a lifespan it'll have since we aim to merge/replace it with WebKit's DumpRenderTree at some point soon. Is there some reason you're not just using Chromium in full screen mode? -- Dirk On Thu, Nov 5, 2009 at 1:18 PM, Alexander Teinum atei...@gmail.com wrote: For a personal project (well, an OS -- check out www.brevityos.org if you're interested), I need something like test_shell in fullscreen mode. The UI is basically an HTML-file with an iframe for every document. CSS-classes are used to describe what application is active, what documents are active etc. The problem is that for my project, test_shell performs bad compared to Chromium. I have compiled with mode set to release, but it's still noticeably slower. I've watched Darin Fisher and Brett Wilson's presentations about the Chromium architecture on YouTube. If I've got it right, then test_shell is below the layer that implements multi-processes. Brett says that test_shell is based on WebKit glue. What needs to be done to make test_shell perform as good as Chromium? I'm not suggesting that test_shell needs to be changed. I'll probably do this in a separate directory under chromium-dir/src, or as a Linux port of Chromium Embedded Framework, if Marshall wants CEF to be multi-processed. -- Best regards, Alexander Teinum -- Best regards/Med vennlig hilsen, Alexander Teinum --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: test_shell performance is bad compared to Chromium
test_shell being a test shell used mostly for non-interactive testing, we haven't given a lot of concern to its perfomance AFAIK. I'm not even sure how long of a lifespan it'll have since we aim to merge/replace it with WebKit's DumpRenderTree at some point soon. Is there some reason you're not just using Chromium in full screen mode? -- Dirk On Thu, Nov 5, 2009 at 1:18 PM, Alexander Teinum atei...@gmail.com wrote: For a personal project (well, an OS -- check out www.brevityos.org if you're interested), I need something like test_shell in fullscreen mode. The UI is basically an HTML-file with an iframe for every document. CSS-classes are used to describe what application is active, what documents are active etc. The problem is that for my project, test_shell performs bad compared to Chromium. I have compiled with mode set to release, but it's still noticeably slower. I've watched Darin Fisher and Brett Wilson's presentations about the Chromium architecture on YouTube. If I've got it right, then test_shell is below the layer that implements multi-processes. Brett says that test_shell is based on WebKit glue. What needs to be done to make test_shell perform as good as Chromium? I'm not suggesting that test_shell needs to be changed. I'll probably do this in a separate directory under chromium-dir/src, or as a Linux port of Chromium Embedded Framework, if Marshall wants CEF to be multi-processed. -- Best regards, Alexander Teinum --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: test_shell performance is bad compared to Chromium
On Thu, Nov 5, 2009 at 1:44 PM, Alexander Teinum atei...@gmail.com wrote: I could probably hack it so that it went into fullscreen, and then disable F11, but that's dirty. All the UI stuff from Chromium would still be there, although it would be hidden. test_shell doesn't implement the fast painting for one. Is the scrolling performance the problem that you're seeing? AGL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: test_shell performance is bad compared to Chromium
This is exactly what i want. Thanks! I'll see if I can make it work. Alexander On Thu, Nov 5, 2009 at 10:51 PM, Nico Weber tha...@chromium.org wrote: http://codereview.chromium.org/244003/show might be what you want. On Thu, Nov 5, 2009 at 1:44 PM, Alexander Teinum atei...@gmail.com wrote: I could probably hack it so that it went into fullscreen, and then disable F11, but that's dirty. All the UI stuff from Chromium would still be there, although it would be hidden. Alexander On Thu, Nov 5, 2009 at 10:32 PM, Dirk Pranke dpra...@chromium.org wrote: test_shell being a test shell used mostly for non-interactive testing, we haven't given a lot of concern to its perfomance AFAIK. I'm not even sure how long of a lifespan it'll have since we aim to merge/replace it with WebKit's DumpRenderTree at some point soon. Is there some reason you're not just using Chromium in full screen mode? -- Dirk On Thu, Nov 5, 2009 at 1:18 PM, Alexander Teinum atei...@gmail.com wrote: For a personal project (well, an OS -- check out www.brevityos.org if you're interested), I need something like test_shell in fullscreen mode. The UI is basically an HTML-file with an iframe for every document. CSS-classes are used to describe what application is active, what documents are active etc. The problem is that for my project, test_shell performs bad compared to Chromium. I have compiled with mode set to release, but it's still noticeably slower. I've watched Darin Fisher and Brett Wilson's presentations about the Chromium architecture on YouTube. If I've got it right, then test_shell is below the layer that implements multi-processes. Brett says that test_shell is based on WebKit glue. What needs to be done to make test_shell perform as good as Chromium? I'm not suggesting that test_shell needs to be changed. I'll probably do this in a separate directory under chromium-dir/src, or as a Linux port of Chromium Embedded Framework, if Marshall wants CEF to be multi-processed. -- Best regards, Alexander Teinum -- Best regards/Med vennlig hilsen, Alexander Teinum -- Best regards/Med vennlig hilsen, Alexander Teinum --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: test_shell performance is bad compared to Chromium
http://codereview.chromium.org/244003/show might be what you want. On Thu, Nov 5, 2009 at 1:44 PM, Alexander Teinum atei...@gmail.com wrote: I could probably hack it so that it went into fullscreen, and then disable F11, but that's dirty. All the UI stuff from Chromium would still be there, although it would be hidden. Alexander On Thu, Nov 5, 2009 at 10:32 PM, Dirk Pranke dpra...@chromium.org wrote: test_shell being a test shell used mostly for non-interactive testing, we haven't given a lot of concern to its perfomance AFAIK. I'm not even sure how long of a lifespan it'll have since we aim to merge/replace it with WebKit's DumpRenderTree at some point soon. Is there some reason you're not just using Chromium in full screen mode? -- Dirk On Thu, Nov 5, 2009 at 1:18 PM, Alexander Teinum atei...@gmail.com wrote: For a personal project (well, an OS -- check out www.brevityos.org if you're interested), I need something like test_shell in fullscreen mode. The UI is basically an HTML-file with an iframe for every document. CSS-classes are used to describe what application is active, what documents are active etc. The problem is that for my project, test_shell performs bad compared to Chromium. I have compiled with mode set to release, but it's still noticeably slower. I've watched Darin Fisher and Brett Wilson's presentations about the Chromium architecture on YouTube. If I've got it right, then test_shell is below the layer that implements multi-processes. Brett says that test_shell is based on WebKit glue. What needs to be done to make test_shell perform as good as Chromium? I'm not suggesting that test_shell needs to be changed. I'll probably do this in a separate directory under chromium-dir/src, or as a Linux port of Chromium Embedded Framework, if Marshall wants CEF to be multi-processed. -- Best regards, Alexander Teinum -- Best regards/Med vennlig hilsen, Alexander Teinum --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: test_shell performance is bad compared to Chromium
test_shell doesn't implement the fast painting for one. Is the scrolling performance the problem that you're seeing? Yes, I perceive the scolling, CSS scale-transformations on the iframes, and moving the iframes around as the biggest performance problems. All of these issues might be related to that? On Thu, Nov 5, 2009 at 10:47 PM, Adam Langley a...@chromium.org wrote: On Thu, Nov 5, 2009 at 1:44 PM, Alexander Teinum atei...@gmail.com wrote: I could probably hack it so that it went into fullscreen, and then disable F11, but that's dirty. All the UI stuff from Chromium would still be there, although it would be hidden. test_shell doesn't implement the fast painting for one. Is the scrolling performance the problem that you're seeing? AGL -- Best regards/Med vennlig hilsen, Alexander Teinum --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: test_shell performance is bad compared to Chromium
Maybe star http://crbug.com/23145 to express your interest. That might motivate mhm to get this ready for checkin. On Thu, Nov 5, 2009 at 1:58 PM, Alexander Teinum atei...@gmail.com wrote: This is exactly what i want. Thanks! I'll see if I can make it work. Alexander On Thu, Nov 5, 2009 at 10:51 PM, Nico Weber tha...@chromium.org wrote: http://codereview.chromium.org/244003/show might be what you want. On Thu, Nov 5, 2009 at 1:44 PM, Alexander Teinum atei...@gmail.com wrote: I could probably hack it so that it went into fullscreen, and then disable F11, but that's dirty. All the UI stuff from Chromium would still be there, although it would be hidden. Alexander On Thu, Nov 5, 2009 at 10:32 PM, Dirk Pranke dpra...@chromium.org wrote: test_shell being a test shell used mostly for non-interactive testing, we haven't given a lot of concern to its perfomance AFAIK. I'm not even sure how long of a lifespan it'll have since we aim to merge/replace it with WebKit's DumpRenderTree at some point soon. Is there some reason you're not just using Chromium in full screen mode? -- Dirk On Thu, Nov 5, 2009 at 1:18 PM, Alexander Teinum atei...@gmail.com wrote: For a personal project (well, an OS -- check out www.brevityos.org if you're interested), I need something like test_shell in fullscreen mode. The UI is basically an HTML-file with an iframe for every document. CSS-classes are used to describe what application is active, what documents are active etc. The problem is that for my project, test_shell performs bad compared to Chromium. I have compiled with mode set to release, but it's still noticeably slower. I've watched Darin Fisher and Brett Wilson's presentations about the Chromium architecture on YouTube. If I've got it right, then test_shell is below the layer that implements multi-processes. Brett says that test_shell is based on WebKit glue. What needs to be done to make test_shell perform as good as Chromium? I'm not suggesting that test_shell needs to be changed. I'll probably do this in a separate directory under chromium-dir/src, or as a Linux port of Chromium Embedded Framework, if Marshall wants CEF to be multi-processed. -- Best regards, Alexander Teinum -- Best regards/Med vennlig hilsen, Alexander Teinum -- Best regards/Med vennlig hilsen, Alexander Teinum --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: test_shell performance is bad compared to Chromium
Maybe star http://crbug.com/23145 to express your interest. That might motivate mhm to get this ready for checkin. Done! :) Alexander On Thu, Nov 5, 2009 at 11:02 PM, Nico Weber tha...@chromium.org wrote: Maybe star http://crbug.com/23145 to express your interest. That might motivate mhm to get this ready for checkin. On Thu, Nov 5, 2009 at 1:58 PM, Alexander Teinum atei...@gmail.com wrote: This is exactly what i want. Thanks! I'll see if I can make it work. Alexander On Thu, Nov 5, 2009 at 10:51 PM, Nico Weber tha...@chromium.org wrote: http://codereview.chromium.org/244003/show might be what you want. On Thu, Nov 5, 2009 at 1:44 PM, Alexander Teinum atei...@gmail.com wrote: I could probably hack it so that it went into fullscreen, and then disable F11, but that's dirty. All the UI stuff from Chromium would still be there, although it would be hidden. Alexander On Thu, Nov 5, 2009 at 10:32 PM, Dirk Pranke dpra...@chromium.org wrote: test_shell being a test shell used mostly for non-interactive testing, we haven't given a lot of concern to its perfomance AFAIK. I'm not even sure how long of a lifespan it'll have since we aim to merge/replace it with WebKit's DumpRenderTree at some point soon. Is there some reason you're not just using Chromium in full screen mode? -- Dirk On Thu, Nov 5, 2009 at 1:18 PM, Alexander Teinum atei...@gmail.com wrote: For a personal project (well, an OS -- check out www.brevityos.org if you're interested), I need something like test_shell in fullscreen mode. The UI is basically an HTML-file with an iframe for every document. CSS-classes are used to describe what application is active, what documents are active etc. The problem is that for my project, test_shell performs bad compared to Chromium. I have compiled with mode set to release, but it's still noticeably slower. I've watched Darin Fisher and Brett Wilson's presentations about the Chromium architecture on YouTube. If I've got it right, then test_shell is below the layer that implements multi-processes. Brett says that test_shell is based on WebKit glue. What needs to be done to make test_shell perform as good as Chromium? I'm not suggesting that test_shell needs to be changed. I'll probably do this in a separate directory under chromium-dir/src, or as a Linux port of Chromium Embedded Framework, if Marshall wants CEF to be multi-processed. -- Best regards, Alexander Teinum -- Best regards/Med vennlig hilsen, Alexander Teinum -- Best regards/Med vennlig hilsen, Alexander Teinum --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: test_shell performance is bad compared to Chromium
On Thu, Nov 5, 2009 at 1:44 PM, Alexander Teinum atei...@gmail.com wrote: I could probably hack it so that it went into fullscreen, and then disable F11, but that's dirty. All the UI stuff from Chromium would still be there, although it would be hidden. Why is that dirty? This is basically kiosk mode, which other people have asked for too. The last time, that ballooned into an enormous unwieldy patch, but just adding a --fullscreen switch wouldn't be so bad. Definitely do not attempt to use test_shell for anything other than testing purposes. It is not, and should not be, a usable or performant product, and as Dirk mentioned, we may eliminate it completely in the future. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: test_shell performance is bad compared to Chromium
On Thu, Nov 5, 2009 at 4:32 PM, Dirk Pranke dpra...@chromium.org wrote: test_shell being a test shell used mostly for non-interactive testing, we haven't given a lot of concern to its perfomance AFAIK. I'm not even sure how long of a lifespan it'll have since we aim to merge/replace it with WebKit's DumpRenderTree at some point soon. So is the plan now for test_shell to go away completely? #3 under *Next steps:* in this email seemed to suggest that it would be up-streamed: http://groups.google.com/group/chromium-dev/browse_thread/thread/5352c2facb46f309 Wouldn't merging/replacing test_shell with DRT eliminate the ability to test the Chromium WebKit API in a simplified environment? Is there some reason you're not just using Chromium in full screen mode? -- Dirk On Thu, Nov 5, 2009 at 1:18 PM, Alexander Teinum atei...@gmail.com wrote: For a personal project (well, an OS -- check out www.brevityos.org if you're interested), I need something like test_shell in fullscreen mode. The UI is basically an HTML-file with an iframe for every document. CSS-classes are used to describe what application is active, what documents are active etc. The problem is that for my project, test_shell performs bad compared to Chromium. I have compiled with mode set to release, but it's still noticeably slower. I've watched Darin Fisher and Brett Wilson's presentations about the Chromium architecture on YouTube. If I've got it right, then test_shell is below the layer that implements multi-processes. Brett says that test_shell is based on WebKit glue. What needs to be done to make test_shell perform as good as Chromium? I'm not suggesting that test_shell needs to be changed. I'll probably do this in a separate directory under chromium-dir/src, or as a Linux port of Chromium Embedded Framework, if Marshall wants CEF to be multi-processed. -- Best regards, Alexander Teinum --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: test_shell performance is bad compared to Chromium
On Thu, Nov 5, 2009 at 1:56 PM, Alexander Teinum atei...@gmail.com wrote: Yes, I perceive the scolling, CSS scale-transformations on the iframes, and moving the iframes around as the biggest performance problems. All of these issues might be related to that? You could try reading chrome/renderer/render_widget.cc, which contains the painting code. You need to implement fast scrolling in at least (ScrollRect) and possible some other things before test_shell will be usable. AGL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: test_shell performance is bad compared to Chromium
Why is that dirty? This is basically kiosk mode, which other people have asked for too. The last time, that ballooned into an enormous unwieldy patch, but just adding a --fullscreen switch wouldn't be so bad. Sorry Dirk, I could have said why I don't think it's an optimal solution. I think it's fine to have components that are not used, as long as they don't eat resources or get in the way. The status bar gets in the way for my project while in fullscreen. There's also a 1 pixel border on top that I don't want. I don't want the user to trigger any of the Chromium UI with the keyboard. A --fullscreen switch could also work. Without being a kiosk computer expert, I'd think that kiosk mode communicates that the program should be restricted. It might prevent the user from going back from fullscreen or exiting Chromium. On Thu, Nov 5, 2009 at 11:06 PM, Peter Kasting pkast...@google.com wrote: On Thu, Nov 5, 2009 at 1:44 PM, Alexander Teinum atei...@gmail.com wrote: I could probably hack it so that it went into fullscreen, and then disable F11, but that's dirty. All the UI stuff from Chromium would still be there, although it would be hidden. Why is that dirty? This is basically kiosk mode, which other people have asked for too. The last time, that ballooned into an enormous unwieldy patch, but just adding a --fullscreen switch wouldn't be so bad. Definitely do not attempt to use test_shell for anything other than testing purposes. It is not, and should not be, a usable or performant product, and as Dirk mentioned, we may eliminate it completely in the future. PK -- Best regards/Med vennlig hilsen, Alexander Teinum --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: test_shell performance is bad compared to Chromium
Whops, I'm saying sorry to Dirk and replying to Peter. Sorry to both of you. ;) On Thu, Nov 5, 2009 at 11:24 PM, Alexander Teinum atei...@gmail.com wrote: Why is that dirty? This is basically kiosk mode, which other people have asked for too. The last time, that ballooned into an enormous unwieldy patch, but just adding a --fullscreen switch wouldn't be so bad. Sorry Dirk, I could have said why I don't think it's an optimal solution. I think it's fine to have components that are not used, as long as they don't eat resources or get in the way. The status bar gets in the way for my project while in fullscreen. There's also a 1 pixel border on top that I don't want. I don't want the user to trigger any of the Chromium UI with the keyboard. A --fullscreen switch could also work. Without being a kiosk computer expert, I'd think that kiosk mode communicates that the program should be restricted. It might prevent the user from going back from fullscreen or exiting Chromium. On Thu, Nov 5, 2009 at 11:06 PM, Peter Kasting pkast...@google.com wrote: On Thu, Nov 5, 2009 at 1:44 PM, Alexander Teinum atei...@gmail.com wrote: I could probably hack it so that it went into fullscreen, and then disable F11, but that's dirty. All the UI stuff from Chromium would still be there, although it would be hidden. Why is that dirty? This is basically kiosk mode, which other people have asked for too. The last time, that ballooned into an enormous unwieldy patch, but just adding a --fullscreen switch wouldn't be so bad. Definitely do not attempt to use test_shell for anything other than testing purposes. It is not, and should not be, a usable or performant product, and as Dirk mentioned, we may eliminate it completely in the future. PK -- Best regards/Med vennlig hilsen, Alexander Teinum -- Best regards/Med vennlig hilsen, Alexander Teinum --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: test_shell performance is bad compared to Chromium
On Thu, Nov 5, 2009 at 1:51 PM, Nico Weber tha...@chromium.org wrote: http://codereview.chromium.org/244003/show might be what you want. I thought this was intentionally abandoned because it was growing out of control. That's what I was alluding to before. On Thu, Nov 5, 2009 at 2:24 PM, Alexander Teinum atei...@gmail.com wrote: There's also a 1 pixel border on top that I don't want. I don't want the user to trigger any of the Chromium UI with the keyboard. What? What OS? There shouldn't be any 1 pixel border in our fullscreen mode. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: test_shell performance is bad compared to Chromium
On Thu, Nov 5, 2009 at 1:59 PM, Marshall Greenblatt magreenbl...@gmail.com wrote: On Thu, Nov 5, 2009 at 4:32 PM, Dirk Pranke dpra...@chromium.org wrote: test_shell being a test shell used mostly for non-interactive testing, we haven't given a lot of concern to its perfomance AFAIK. I'm not even sure how long of a lifespan it'll have since we aim to merge/replace it with WebKit's DumpRenderTree at some point soon. So is the plan now for test_shell to go away completely? #3 under *Next steps:* in this email seemed to suggest that it would be up-streamed: http://groups.google.com/group/chromium-dev/browse_thread/thread/5352c2facb46f309 Wouldn't merging/replacing test_shell with DRT eliminate the ability to test the Chromium WebKit API in a simplified environment? Good question, and I didn't actually know the answer, so that provoked an interesting but short discussion between Ojan and Dimitri and myself. At the moment we're leaning to keeping test_shell and DumpRenderTree both. The latter would be the driver for the layout test harness (as it is upstream), and test_shell would get all of the layout test code ripped out of it and become more like an actual shell that can be used to embed webkit for interactive work (and upstreamed, as you say). The exact functionality and distinctions between the two (and the justification of the existence of both) probably still needs some edges smoothed. -- Dirk --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: test_shell performance is bad compared to Chromium
What? What OS? There shouldn't be any 1 pixel border in our fullscreen mode. It's in the Linux-version. In BrowserWindowGtk::InitWidgets() there’s this line: gtk_widget_set_size_request(toolbar_border_, -1, 1); I changed it into: gtk_widget_set_size_request(toolbar_border_, -1, -1); That got rid of it, but that also removes it from the normal mode, where it should be. It's the line between the web browser view and the toolbars above. On Thu, Nov 5, 2009 at 11:33 PM, Peter Kasting pkast...@google.com wrote: On Thu, Nov 5, 2009 at 1:51 PM, Nico Weber tha...@chromium.org wrote: http://codereview.chromium.org/244003/show might be what you want. I thought this was intentionally abandoned because it was growing out of control. That's what I was alluding to before. On Thu, Nov 5, 2009 at 2:24 PM, Alexander Teinum atei...@gmail.com wrote: There's also a 1 pixel border on top that I don't want. I don't want the user to trigger any of the Chromium UI with the keyboard. What? What OS? There shouldn't be any 1 pixel border in our fullscreen mode. PK -- Best regards/Med vennlig hilsen, Alexander Teinum --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: test_shell performance is bad compared to Chromium
On Thu, Nov 5, 2009 at 2:46 PM, Alexander Teinum atei...@gmail.com wrote: What? What OS? There shouldn't be any 1 pixel border in our fullscreen mode. It's in the Linux-version. In BrowserWindowGtk::InitWidgets() there’s this line: gtk_widget_set_size_request(toolbar_border_, -1, 1); I changed it into: gtk_widget_set_size_request(toolbar_border_, -1, -1); That got rid of it, but that also removes it from the normal mode, where it should be. It's the line between the web browser view and the toolbars above. If you can provide a patch to do the right thing (no line in fullscreen mode), that'd be awesome, otherwise can you file a bug about this? PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: test_shell performance is bad compared to Chromium
On Thu, Nov 5, 2009 at 2:46 PM, Alexander Teinum atei...@gmail.com wrote: It's in the Linux-version. You should have mentioned the platform. You have an awful lot of work to get the Linux test_shell up to Chromium speeds. There's a lot of raw Xlib calls to keep the image of the page in video memory and to try and use accelerated blits to scroll. AGL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: test_shell performance is bad compared to Chromium
Sure. I'm not into the patching process yet, but give me a couple of days, and I'll try to get it fixed. Alexander On Thu, Nov 5, 2009 at 11:48 PM, Peter Kasting pkast...@google.com wrote: On Thu, Nov 5, 2009 at 2:46 PM, Alexander Teinum atei...@gmail.com wrote: What? What OS? There shouldn't be any 1 pixel border in our fullscreen mode. It's in the Linux-version. In BrowserWindowGtk::InitWidgets() there’s this line: gtk_widget_set_size_request(toolbar_border_, -1, 1); I changed it into: gtk_widget_set_size_request(toolbar_border_, -1, -1); That got rid of it, but that also removes it from the normal mode, where it should be. It's the line between the web browser view and the toolbars above. If you can provide a patch to do the right thing (no line in fullscreen mode), that'd be awesome, otherwise can you file a bug about this? PK -- Best regards/Med vennlig hilsen, Alexander Teinum --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: test_shell performance is bad compared to Chromium
On Thu, Nov 5, 2009 at 2:51 PM, Adam Langley a...@chromium.org wrote: You have an awful lot of work to get the Linux test_shell up to Chromium speeds. I'm really opposed to doing work like this on test_shell. It's not just that it's a waste of time. One of the reasons we have test_shell is to be as simple an app as possible, so that it's easy to test things and obvious where the problems are when things go wrong. Making test_shell more optimized and performant pretty much necessarily means making it less braindead-obvious. That's bad. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: test_shell performance is bad compared to Chromium
-- Evan Stade On Thu, Nov 5, 2009 at 2:48 PM, Peter Kasting pkast...@google.com wrote: On Thu, Nov 5, 2009 at 2:46 PM, Alexander Teinum atei...@gmail.comwrote: What? What OS? There shouldn't be any 1 pixel border in our fullscreen mode. It's in the Linux-version. In BrowserWindowGtk::InitWidgets() there’s this line: gtk_widget_set_size_request(toolbar_border_, -1, 1); I changed it into: gtk_widget_set_size_request(toolbar_border_, -1, -1); That got rid of it, but that also removes it from the normal mode, where it should be. It's the line between the web browser view and the toolbars above. ah, this is my fault. Of course that is not the intended behavior... I'll fix. If you can provide a patch to do the right thing (no line in fullscreen mode), that'd be awesome, otherwise can you file a bug about this? PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: test_shell performance is bad compared to Chromium
On Thu, Nov 5, 2009 at 5:33 PM, Peter Kasting pkast...@google.com wrote: On Thu, Nov 5, 2009 at 1:51 PM, Nico Weber tha...@chromium.org wrote: http://codereview.chromium.org/244003/show might be what you want. I thought this was intentionally abandoned because it was growing out of control. That's what I was alluding to before. Not entirely abandoned, true it was getting out of control and that is why I stopped to take a step back. Technically it should be what I did for patch set one, which is just fullscreen + no statusbar. That is basically what the functionality is. I will continue working on it tonight. - Mohamed Mansour --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: test_shell performance is bad compared to Chromium
I want to make it clear, and it might be obvious by now, but test_shell isn't interesting to me. I just want the fastest browser engine that I can get. What makes Chromium different than WebKitGTK+ for my project, is that Chromium renders the GTK stuff correctly with CSS transformations. It's also snappier. Making the rendering part of Chromium easier to use for open source project would benefit projects such as mine or uzbl for instance. uzbl is a WebKitGTK+ browser that is controlled similar to Vim. I realize that CEF is an effort at making it easier to embed Chromium, but if it's based on test_shell, then well... what about the platform optimalizations? Are they easy to get into CEF, or does it have to play catch-up? On Fri, Nov 6, 2009 at 12:21 AM, Mohamed Mansour m...@chromium.org wrote: On Thu, Nov 5, 2009 at 5:33 PM, Peter Kasting pkast...@google.com wrote: On Thu, Nov 5, 2009 at 1:51 PM, Nico Weber tha...@chromium.org wrote: http://codereview.chromium.org/244003/show might be what you want. I thought this was intentionally abandoned because it was growing out of control. That's what I was alluding to before. Not entirely abandoned, true it was getting out of control and that is why I stopped to take a step back. Technically it should be what I did for patch set one, which is just fullscreen + no statusbar. That is basically what the functionality is. I will continue working on it tonight. - Mohamed Mansour -- Best regards/Med vennlig hilsen, Alexander Teinum --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: test_shell performance is bad compared to Chromium
On Thu, Nov 5, 2009 at 3:34 PM, Alexander Teinum atei...@gmail.com wrote: Making the rendering part of Chromium easier to use for open source project would benefit projects such as mine or uzbl for instance. uzbl is a WebKitGTK+ browser that is controlled similar to Vim. This is one of the reasons we are trying to upstream our WebKit API embedding layer. See a recent post by Darin Fisher on webkit-dev. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
