[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: SVG tests and sanity
From what I've seen, a large portion of the svg tests fail due to pretty fundamental svg implementation issues. In addition, many of the tests fail due to the same bug/root cause. I think Dimitri is right that the best approach here is a smaller, more focused effort whether or not fixing these by 2.0 is a priority. J On Fri, Mar 13, 2009 at 12:28 PM, Scott Violet s...@chromium.org wrote: On thinking about this a bit more this would mean a break from our policy of no rendering regressions since 1.0. Are we OK with that decision? -Scott On Fri, Mar 13, 2009 at 11:28 AM, Scott Violet s...@chromium.org wrote: YES! DEFER! -Scott On Fri, Mar 13, 2009 at 11:25 AM, Dimitri Glazkov dglaz...@google.com wrote: Team, We have many brains working the layout test puzzle. And that's a good thing. We've got this Rubik's cube nearly all finished. However, it somewhat pains me seeing lots of engineers spending countless hours trying to fix the SVG tests. Perhaps we shouldn't be doing that? I mean, based on my experience, SVG accounts for a tiny fraction of the Web and very (very!) few pages will be broken even if we completely ignore SVG. IMHO, a better approach will be deferring these tests and trying to tackle them later as a smaller, more focused effort. Identify the experts in drawing and SVG markup, WebKit implementation, and let them fix it. WDYT? :DG --~--~-~--~~~---~--~~ 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] New waterfall Developer View.
Hello! A lot of people told me that they did not like the waterfall, mainly because it's hard to find out where and when a change is tested, and what the result is. (It involves a lot of scrolling, searching, etc). So I tried to write a better one. The goal of this new waterfall is to be more developer and revision centric. It shows the status of all builders per revision, without scrolling. It is also customizable. You can configure it to show only your changes, or the changes of other people in your sub-team. I wrote it as a proof of concept, but it seems to work nicely. I really want to hear your suggestions. Let me know what would be better, and what other information you would like from the buildbot. More details (including an explanation of the UI): http://sites.google.com/a/chromium.org/dev/developers/testing/waterfall-developer-view *NOTE* : You might need to clean your cache. It seems like chrome does not want to reload the current buildbot css file. NOTE: This does not completely replaced the waterfall. Sheriffs should continue looking at the waterfall as the main source of information. I'm waiting for your comments! Thanks, Nicolas --~--~-~--~~~---~--~~ 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: New waterfall Developer View.
Wow - thanks Nicolas! This looks really interesting. I look forward to seeing it in action this week! Mike On Sun, Mar 15, 2009 at 6:54 PM, Nicolas Sylvain nsylv...@chromium.orgwrote: Hello! A lot of people told me that they did not like the waterfall, mainly because it's hard to find out where and when a change is tested, and what the result is. (It involves a lot of scrolling, searching, etc). So I tried to write a better one. The goal of this new waterfall is to be more developer and revision centric. It shows the status of all builders per revision, without scrolling. It is also customizable. You can configure it to show only your changes, or the changes of other people in your sub-team. I wrote it as a proof of concept, but it seems to work nicely. I really want to hear your suggestions. Let me know what would be better, and what other information you would like from the buildbot. More details (including an explanation of the UI): http://sites.google.com/a/chromium.org/dev/developers/testing/waterfall-developer-view *NOTE* : You might need to clean your cache. It seems like chrome does not want to reload the current buildbot css file. NOTE: This does not completely replaced the waterfall. Sheriffs should continue looking at the waterfall as the main source of information. I'm waiting for your comments! Thanks, Nicolas --~--~-~--~~~---~--~~ 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: New waterfall Developer View.
Wow Nicolas! Very nice :) One comment, can you make urls auto link. Many commits they place their code review / issue tracker url, but its not linkable. Would be cool to have that :) On Sun, Mar 15, 2009 at 10:33 PM, Mike Belshe mbel...@google.com wrote: Wow - thanks Nicolas! This looks really interesting. I look forward to seeing it in action this week! Mike On Sun, Mar 15, 2009 at 6:54 PM, Nicolas Sylvain nsylv...@chromium.org wrote: Hello! A lot of people told me that they did not like the waterfall, mainly because it's hard to find out where and when a change is tested, and what the result is. (It involves a lot of scrolling, searching, etc). So I tried to write a better one. The goal of this new waterfall is to be more developer and revision centric. It shows the status of all builders per revision, without scrolling. It is also customizable. You can configure it to show only your changes, or the changes of other people in your sub-team. I wrote it as a proof of concept, but it seems to work nicely. I really want to hear your suggestions. Let me know what would be better, and what other information you would like from the buildbot. More details (including an explanation of the UI): http://sites.google.com/a/chromium.org/dev/developers/testing/waterfall-developer-view NOTE : You might need to clean your cache. It seems like chrome does not want to reload the current buildbot css file. NOTE: This does not completely replaced the waterfall. Sheriffs should continue looking at the waterfall as the main source of information. I'm waiting for your comments! Thanks, Nicolas --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] [extensions] Zotero
Here's a pretty sweet Firefox extension that we should be able to someday support. Tons of features. Lots of very well done UI. Watch the video: http://www.zotero.org/ - a --~--~-~--~~~---~--~~ 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: SVG tests and sanity
On Fri, Mar 13, 2009 at 4:49 PM, Scott Violet s...@chromium.org wrote: Those are easy. If the test never worked them DEFER. I agree, if it's not a regression, and (as Linus mentioned) not a hang/crash/leak, let's punt. I only care about not regressing tests that are regressions, not sure how many of those there are. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
