[chromium-dev] Re: Doing some research with views and GTK.
I added a couple of benefits of using Views on Linux to the spread sheet. I have a couple of comments on advantages of using GTK directly: Font size changes (e.g., changing the system font size will apply to our dialogs) Is there a reason why we couldn't resize based on the system font size? Accessibility for buttons and dialogs (but not for tabstrip and bookmarks) Better RTL These are weaknesses with our Windows implementation too. If we're willing to live with them on Windows, is there a reason why we couldn't live with them on Linux? A better change at good remote X performance? As has already been mentioned the actual UI is a small fraction of Chrome, especially when most interaction is done with the page and not the UI. Gtk widgets will automatically feel and behave like Linux This only applies to places where we can use standard widgets. The tab strip is custom, so that you won't get exact fidelity there irregardless of whether we use GTK directly. The bookmark bar may have similar issues. -Scott On Fri, Mar 13, 2009 at 8:43 PM, t...@chromium.org wrote: I started a page describing some of the high level tradeoffs between the two. Please add items or elaborate. http://code.google.com/p/chromium/wiki/GtkVsViewsGtk On Fri, 13 Mar 2009, Ben Goodger (Google) wrote: Scott Violet, Elliot, Evan Martin, Adam Langley, Tony, Linus and I met briefly earlier today to discuss Linux UI and Gtk. What we agreed is that next week Elliot and I will spend some time researching what it would take to use views with Gtk, including the Widget/Window types and NativeControl. The plan is to use native Gtk widgets for the outer container and for all locations where a NativeControl is used on Windows, so the applicable system integration for things like IME in text fields should just work. In this capacity, views is used as a layout engine and an event receiver/propagation system for views that aren't GtkWidgets, as it is on Windows for widgets that aren't HWNDs/Common Controls. As usual, Skia is providing the rendering. Since we're just researching right now, don't let this delay any UI work that's already under way. We'll report back to this group at the end of next week with our findings. -Ben --~--~-~--~~~---~--~~ 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: Doing some research with views and GTK.
On Mon, 16 Mar 2009, Scott Violet wrote: Font size changes (e.g., changing the system font size will apply to our dialogs) Is there a reason why we couldn't resize based on the system font size? Better RTL These are weaknesses with our Windows implementation too. If we're willing to live with them on Windows, is there a reason why we couldn't live with them on Linux? Yes, both of these are things that we could implement in Views, but it requires more effort on our part. Also, each bug that we have in Views that isn't in GTK is another reason for the app not feeling native. I agree that both the tab strip and bookmarks bar should share as much code as possible with the windows side. Maybe that means using Views for those pieces. But I think using Views for the various dialogs (about, options, password manager, task manager, search keywords, etc) will feel very strange unless we try to mimic the GTK layout engine. tony --~--~-~--~~~---~--~~ 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: Doing some research with views and GTK.
On Mon, Mar 16, 2009 at 10:54 AM, Scott Violet s...@chromium.org wrote: I added a couple of benefits of using Views on Linux to the spread sheet. I have a couple of comments on advantages of using GTK directly: Font size changes (e.g., changing the system font size will apply to our dialogs) Is there a reason why we couldn't resize based on the system font size? FYI, we don't do this on windows either. Typically there's a message that the window has to handle by just calling Layout() to relayout all its contents at the new font sizes. Accessibility for buttons and dialogs (but not for tabstrip and bookmarks) Better RTL These are weaknesses with our Windows implementation too. If we're willing to live with them on Windows, is there a reason why we couldn't live with them on Linux? We'd have to implement these APIs on Linux anyway for the custom-rendered tabstrip. From some basic digging it sounds like Gtk provides APIs similar to IAccessible in Atk that you implement. Maybe Jonas knows more. -Ben --~--~-~--~~~---~--~~ 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: Doing some research with views and GTK.
On Mon, Mar 16, 2009 at 11:49 AM, Ben Goodger (Google) b...@chromium.org wrote: We'd have to implement these APIs on Linux anyway for the custom-rendered tabstrip. From some basic digging it sounds like Gtk provides APIs similar to IAccessible in Atk that you implement. Maybe Jonas knows more. I think it's not in Gtk per se, but next to it; see http://www.linuxfoundation.org/en/Accessibility --~--~-~--~~~---~--~~ 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: Doing some research with views and GTK.
I had a discussion about Views with Scott. I think I am on the side of the fence that porting views it not a good idea. One of the things that came up is remote X, would it be possible to ever have good remote X performance with the Views panting model? I wouldn't want to paint ourselves into a corner (dum dum dum). On Sat, Mar 14, 2009 at 4:43 AM, t...@chromium.org wrote: I started a page describing some of the high level tradeoffs between the two. Please add items or elaborate. http://code.google.com/p/chromium/wiki/GtkVsViewsGtk On Fri, 13 Mar 2009, Ben Goodger (Google) wrote: Scott Violet, Elliot, Evan Martin, Adam Langley, Tony, Linus and I met briefly earlier today to discuss Linux UI and Gtk. What we agreed is that next week Elliot and I will spend some time researching what it would take to use views with Gtk, including the Widget/Window types and NativeControl. The plan is to use native Gtk widgets for the outer container and for all locations where a NativeControl is used on Windows, so the applicable system integration for things like IME in text fields should just work. In this capacity, views is used as a layout engine and an event receiver/propagation system for views that aren't GtkWidgets, as it is on Windows for widgets that aren't HWNDs/Common Controls. As usual, Skia is providing the rendering. Since we're just researching right now, don't let this delay any UI work that's already under way. We'll report back to this group at the end of next week with our findings. -Ben --~--~-~--~~~---~--~~ 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: Doing some research with views and GTK.
On Sat, Mar 14, 2009 at 12:59 AM, Ben Goodger (Google) b...@chromium.org wrote: Scott Violet, Elliot, Evan Martin, Adam Langley, Tony, Linus and I met briefly earlier today to discuss Linux UI and Gtk. What we agreed is that next week Elliot and I will spend some time researching what it would take to use views with Gtk, including the Widget/Window types and NativeControl. The plan is to use native Gtk widgets for the outer container and for all locations where a NativeControl is used on Windows, so the applicable system integration for things like IME in text fields should just work. In this capacity, views is used as a layout engine and an event receiver/propagation system for views that aren't GtkWidgets, as it is on Windows for widgets that aren't HWNDs/Common Controls. As usual, Skia is providing the rendering. I think it's important to point our here that Skia (well ChromeCanvas) is not equal on Linux and Windows. Specifically Windows draws text using GDI, which current is much more powerful than drawing text using Skia. Until Skia has a text layout engine, panting text with Skia is basically a no go. We would still need to draw the text with Pango / Cairo, but we could incorporate that into ChromeCanvas... Since we're just researching right now, don't let this delay any UI work that's already under way. We'll report back to this group at the end of next week with our findings. -Ben --~--~-~--~~~---~--~~ 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: Doing some research with views and GTK.
On Sun, Mar 15, 2009 at 7:37 AM, Dean McNamee de...@chromium.org wrote: I had a discussion about Views with Scott. I think I am on the side of the fence that porting views it not a good idea. One of the things that came up is remote X, would it be possible to ever have good remote X performance with the Views panting model? I wouldn't want to paint ourselves into a corner (dum dum dum). It was my understanding we were already using Skia for a lot of this drawing, so the existing approach wasn't going to make remote X too happy either. Brett --~--~-~--~~~---~--~~ 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: Doing some research with views and GTK.
On Sun, Mar 15, 2009 at 8:55 AM, Dean McNamee de...@chromium.org wrote: UI elements like buttons are different, my understanding is that (at least in theory) it should be possible for all of those images of the different states to live on the X server, so they don't need to be sent over the network for every expose. I'm not sure how we would do this with a Skia based drawing pipeline. Although a displaylist like interface would be very nice, it's basically not going to happen. However, I wouldn't worry about drawing the UI elements as a bitmap too much. Firstly, the number of pixels isn't that large. The TabStrip, Omnibox, buttons etc probably take up 5% of the screen, when Chrome is fullscreen. If we are careful only to repaint that which needs to be repainted, then most of the time, the new-pixel delta is much smaller still. If, even after all that, there are issues with desktop switching causing a slow repaint etc, then I have other tricks up my sleeve. 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: Doing some research with views and GTK.
On Sun, Mar 15, 2009 at 10:09 AM, Adam Langley a...@chromium.org wrote: On Sun, Mar 15, 2009 at 8:55 AM, Dean McNamee de...@chromium.org wrote: UI elements like buttons are different, my understanding is that (at least in theory) it should be possible for all of those images of the different states to live on the X server, so they don't need to be sent over the network for every expose. I'm not sure how we would do this with a Skia based drawing pipeline. Although a displaylist like interface would be very nice, it's basically not going to happen. However, I wouldn't worry about drawing the UI elements as a bitmap too much. Firstly, the number of pixels isn't that large. The TabStrip, Omnibox, buttons etc probably take up 5% of the screen, This is a good point. It probably doesn't matter what we do with the tabstrip and toolbar when the page is rendered to a giant DIB. While I would like to do a displaylist-like painting for the page, I don't see this happening in a way that can be reasonably remotable on X. Brett --~--~-~--~~~---~--~~ 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: Doing some research with views and GTK.
Evan told Scott and I you were rendering into Skia in a few places, then converting into a native image format and pushing to the display. -Ben On Sun, Mar 15, 2009 at 8:55 AM, Dean McNamee de...@chromium.org wrote: I don't believe we are currently using Skia for any of our UI drawing. We draw the renderer with Skia, and Adam has done a bunch of work to make sure that backing store can live on the X server for fast scrolling, etc. But that is a completely different sort of thing (transport dibs, backing stores, etc). UI elements like buttons are different, my understanding is that (at least in theory) it should be possible for all of those images of the different states to live on the X server, so they don't need to be sent over the network for every expose. I'm not sure how we would do this with a Skia based drawing pipeline. On Sun, Mar 15, 2009 at 4:42 PM, Brett Wilson bre...@chromium.org wrote: On Sun, Mar 15, 2009 at 7:37 AM, Dean McNamee de...@chromium.org wrote: I had a discussion about Views with Scott. I think I am on the side of the fence that porting views it not a good idea. One of the things that came up is remote X, would it be possible to ever have good remote X performance with the Views panting model? I wouldn't want to paint ourselves into a corner (dum dum dum). It was my understanding we were already using Skia for a lot of this drawing, so the existing approach wasn't going to make remote X too happy either. Brett --~--~-~--~~~---~--~~ 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: Doing some research with views and GTK.
I started a page describing some of the high level tradeoffs between the two. Please add items or elaborate. http://code.google.com/p/chromium/wiki/GtkVsViewsGtk On Fri, 13 Mar 2009, Ben Goodger (Google) wrote: Scott Violet, Elliot, Evan Martin, Adam Langley, Tony, Linus and I met briefly earlier today to discuss Linux UI and Gtk. What we agreed is that next week Elliot and I will spend some time researching what it would take to use views with Gtk, including the Widget/Window types and NativeControl. The plan is to use native Gtk widgets for the outer container and for all locations where a NativeControl is used on Windows, so the applicable system integration for things like IME in text fields should just work. In this capacity, views is used as a layout engine and an event receiver/propagation system for views that aren't GtkWidgets, as it is on Windows for widgets that aren't HWNDs/Common Controls. As usual, Skia is providing the rendering. Since we're just researching right now, don't let this delay any UI work that's already under way. We'll report back to this group at the end of next week with our findings. -Ben --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
