[chromium-dev] Pixel layout tests and checksums
Last week I updated our DEPS to pull in a newer version of Skia. I was stumped at a few cases where the checked in PNG looked completely wrong, but yet it was passing on the buildbots. There was no way that image could have been the output. It just dawned on me today, but I haven't verified it. I can dig up my commit to verify it, but I'd say 99% sure this was the case. If the checksum is valid, we don't even go to the PNG. Therefor I believe we have a bunch of layout tests where the checked in PNG is completely wrong, but the checksum is right. I don't have the time right now, but it would be great if someone could write a script and clean this up. Thanks -- dean --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Error While compiling on ubuntu 64bit
Hi, I am getting error while compiling on ubuntu 9.04 (64bit) /home/ibrar/Google/chromium/src/third_party/WebKit/WebCore/css/CSSParser.cpp: In function 'int WebCore::cssValueKeywordID(const WebCore::CSSParserString)': /home/ibrar/Google/chromium/src/third_party/WebKit/WebCore/css/CSSParser.cpp:4947: error: expected initializer before '*' token /home/ibrar/Google/chromium/src/third_party/WebKit/WebCore/css/CSSParser.cpp:4948: error: 'hashTableEntry' was not declared in this scope Compiling /home/ibrar/Google/chromium/src/sconsbuild/Debug/obj/third_party/WebKit/WebCore/css/CSSPropertyLonghand.o scons: *** [/home/ibrar/Google/chromium/src/sconsbuild/Debug/obj/third_party/WebKit/WebCore/css/CSSParser.o] Error 1 scons: building terminated because of errors. On Sat, Jun 20, 2009 at 4:45 AM, Hunnter2k3 hunn...@gmail.com wrote: Ever since V2 has been pushed, the CPU usage for Chrome has sky- rocketed every time i am loading pages. Every time a page is loading, both cores are hitting 100%. Worse is when sites are lagging or slow, the CPU is still at 100% until it is finished, no ifs or buts. I even done a fresh install, I even installed SRWare's Iron, it still hits 100% when a page loads. If this is what V2 is going to be like, i am going straight back to V1, i don't want a browser eating 100% and interrupting other processes, especially if it is because of a feature i couldn't care less about. Is this what has happened to Full Page Zoom now, instead of generating it each time a person wants to zoom? If so, for the love of everything decent, please go back to the old system, i don't care for FPZ and never will, or at least start using that wonderful thing called Options and add it in there, please. -- Ibrar Ahmed --~--~-~--~~~---~--~~ 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: Pixel layout tests and checksums
While we're wishing, I'll add that verifying this should be added to the presubmit script (if you touched any layout tests). On Mon, Jun 22, 2009 at 3:20 AM, Dean McNameede...@chromium.org wrote: Last week I updated our DEPS to pull in a newer version of Skia. I was stumped at a few cases where the checked in PNG looked completely wrong, but yet it was passing on the buildbots. There was no way that image could have been the output. It just dawned on me today, but I haven't verified it. I can dig up my commit to verify it, but I'd say 99% sure this was the case. If the checksum is valid, we don't even go to the PNG. Therefor I believe we have a bunch of layout tests where the checked in PNG is completely wrong, but the checksum is right. I don't have the time right now, but it would be great if someone could write a script and clean this up. Thanks -- dean --~--~-~--~~~---~--~~ 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: Memory usage in chrome
2009/6/21 PhistucK phist...@gmail.com Really? the statistics show that many people are using the app mode?Or did you mean web apps, as in web application websites? I mean web applications like gmail, hotmail, zoho, shopping carts, etc etc. But it's an unsubstantiated claim. Mike ☆PhistucK On Sun, Jun 21, 2009 at 21:03, Mike Belshe mbel...@google.com wrote: I assume he's not a benchmark pro, but he did a decent job already. We can nitpick his sampling methodology - but it won't change the result. He is correct that many procs is far more memory consuming than single proc, and we already knew this. This is a tradeoff we made consciously and deliberately. When firefox crashes, all tabs go down. When firefox memory is compromised (security), all tabs are compromised. In chrome, we don't have those problems, but instead use more RAM. Further, Chrome is also able to implement per-tab prioritization, so that background tabs don't make foreground tabs go slow. Firefox can't do that. Lastly, lets bring the test back to reality. People don't visit 150 random home pages. They may have 20-30 tabs open, but many are applications, with cookies, javascript state and much more than just the home page. When apps are in use, the memory gap between chrome and FF shrinks a lot. Mike On Sun, Jun 21, 2009 at 10:46 AM, Dan Kegel d...@kegel.com wrote: On Sun, Jun 21, 2009 at 10:22 AM, Mike Belshembel...@google.com wrote: First off - kudos to the author for posting the source and steps to reproduce! Most don't do that! Second, the author is basically right. Since he's running on Vista, its a bit hard to tell whether his stats included shared memory or not; using the default memory statistic (Memory (Private Working Set)) is actually a pretty good measure to just sum. But he doesn't say which measurement he used. Wait, why doesn't his program itself do the summing? (I don't see it in there.) Wouldn't that get rid of the ambiguity? How hard would it be to add that and repost? - Dan --~--~-~--~~~---~--~~ 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: Pixel layout tests and checksums
Can we put this in a bug for easier trackage? :DG On Mon, Jun 22, 2009 at 5:58 AM, Evan Martine...@chromium.org wrote: While we're wishing, I'll add that verifying this should be added to the presubmit script (if you touched any layout tests). On Mon, Jun 22, 2009 at 3:20 AM, Dean McNameede...@chromium.org wrote: Last week I updated our DEPS to pull in a newer version of Skia. I was stumped at a few cases where the checked in PNG looked completely wrong, but yet it was passing on the buildbots. There was no way that image could have been the output. It just dawned on me today, but I haven't verified it. I can dig up my commit to verify it, but I'd say 99% sure this was the case. If the checksum is valid, we don't even go to the PNG. Therefor I believe we have a bunch of layout tests where the checked in PNG is completely wrong, but the checksum is right. I don't have the time right now, but it would be great if someone could write a script and clean this up. Thanks -- dean --~--~-~--~~~---~--~~ 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: Memory usage in chrome
On 21-Jun-09, at 10:22 AM, Mike Belshe wrote: Second, the author is basically right. Since he's running on Vista, its a bit hard to tell whether his stats included shared memory or not; using the default memory statistic (Memory (Private Working Set)) is actually a pretty good measure to just sum. But he doesn't say which measurement he used. Doesn't Private Bytes accurately represent the private memory for a given process? I thought the whole point of that was that it didn't measure any shared memory pools. cheers, mike --~--~-~--~~~---~--~~ 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: Chrome CHECKs on startup (debug build, from HEAD, last 2 days)
Did clean build (whole solution), got DCHECK on extension_prefs.cc(54), added --enable-extensions to startup and now it works. On Fri, Jun 19, 2009 at 1:48 PM, Nebojša Ćirić c...@chromium.org wrote: I am on Vista (win build). On Fri, Jun 19, 2009 at 1:46 PM, Nebojša Ćirić c...@chromium.org wrote: For last 2 days when I start chrome I get FATAL:tab_renderer.cc(123) Check failed: waiting_animation_frames-width() % waiting_animation_frames-height() == 0. I am synced to HEAD, rebuild whole solution (debug mode). Did anybody else stumble on this problem? Also, building chrome project doesn't build chrome_resources project (which results in check on startup). Cira --~--~-~--~~~---~--~~ 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: Memory usage in chrome
I built a web based application in php to upload dvd vob files to a server via the browser. The only browser that makes this project a non failure is chrome. Forget trying to upload 4+ gigs with Internet Explorer. It can not handle the memory addressing. Firefox fails 90% of the time. However chrome always gets the 4 gigs over the web interface. Chrome, an actual browser that doesnt need compatibility buttons, and also can handle moving 4+gigs with the browser. Chrome is kick ass. On Jun 22, 12:21 am, PhistucK phist...@gmail.com wrote: Really? the statistics show that many people are using the app mode?Or did you mean web apps, as in web application websites? ☆PhistucK On Sun, Jun 21, 2009 at 21:03, Mike Belshe mbel...@google.com wrote: I assume he's not a benchmark pro, but he did a decent job already. We can nitpick his sampling methodology - but it won't change the result. He is correct that many procs is far more memory consuming than single proc, and we already knew this. This is a tradeoff we made consciously and deliberately. When firefox crashes, all tabs go down. When firefox memory is compromised (security), all tabs are compromised. In chrome, we don't have those problems, but instead use more RAM. Further, Chrome is also able to implement per-tab prioritization, so that background tabs don't make foreground tabs go slow. Firefox can't do that. Lastly, lets bring the test back to reality. People don't visit 150 random home pages. They may have 20-30 tabs open, but many are applications, with cookies, javascript state and much more than just the home page. When apps are in use, the memory gap between chrome and FF shrinks a lot. Mike On Sun, Jun 21, 2009 at 10:46 AM, Dan Kegel d...@kegel.com wrote: On Sun, Jun 21, 2009 at 10:22 AM, Mike Belshembel...@google.com wrote: First off - kudos to the author for posting the source and steps to reproduce! Most don't do that! Second, the author is basically right. Since he's running on Vista, its a bit hard to tell whether his stats included shared memory or not; using the default memory statistic (Memory (Private Working Set)) is actually a pretty good measure to just sum. But he doesn't say which measurement he used. Wait, why doesn't his program itself do the summing? (I don't see it in there.) Wouldn't that get rid of the ambiguity? How hard would it be to add that and repost? - Dan --~--~-~--~~~---~--~~ 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: Chrome CHECKs on startup (debug build, from HEAD, last 2 days)
I am on Vista (win build). On Fri, Jun 19, 2009 at 1:46 PM, Nebojša Ćirić c...@chromium.org wrote: For last 2 days when I start chrome I get FATAL:tab_renderer.cc(123) Check failed: waiting_animation_frames-width() % waiting_animation_frames-height() == 0. I am synced to HEAD, rebuild whole solution (debug mode). Did anybody else stumble on this problem? Also, building chrome project doesn't build chrome_resources project (which results in check on startup). Cira --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Chrome CHECKs on startup (debug build, from HEAD, last 2 days)
For last 2 days when I start chrome I get FATAL:tab_renderer.cc(123) Check failed: waiting_animation_frames-width() % waiting_animation_frames-height() == 0. I am synced to HEAD, rebuild whole solution (debug mode). Did anybody else stumble on this problem? Also, building chrome project doesn't build chrome_resources project (which results in check on startup). Cira --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Fwd: [chromium-discuss] Integrating Chromium to my project
Definitely a question for chromium-dev... -- Forwarded message -- From: Dinge Raphael raphael.di...@gmail.com Date: Mon, Jun 22, 2009 at 5:45 AM Subject: [chromium-discuss] Integrating Chromium to my project To: chromium-disc...@googlegroups.com Hi, (I'm not sure if this mail would be better on chromium-dev so I post here just in case) I've a tiny problem into integrating chromium into my project. My project is a portable graphical library with features directly targeted at our application. Basically once we have a window, we have a portable implementation of objects similar to MacOS X NSView or Windows child windows, except that rendering is made in a high priority thread synced with screen vertical retrace using high performance OpenGL or DirectX libraries. While trying to integrate first on MacOS X chromium into my project, I tried to get rid of the NSView implementation used by chromium. This is a success, and the general idea is that an OS event is converted to our format of event, and we only had to convert our event in the event format of WebKit, then pass it to an instance of WebView. We also implemented a WebViewDelegate and react as appropriate to notifications. Rendering are made with skia, then the portion of memory representing the page is sent to the video thread which display it. Everything is fine at this point : Chromium is integrated into our graphical engine... almost. The only problem that remains is about the message pump. Basically the message pump takes over the system events and manage them. This was not a big issue, as our engine has been made to be integrated as a plug-in also. So for now instead of calling CFLoopRunLoop (), I'm using the message pump ui, and run this message pump. Architecturally, the problem is that this behavior is more like integrating our engine into Chromium. Furthermore, I now need to integrate Chromium as a plug-in of our engine, which means I cannot rely on the Chromium message pump to be there. I first thought that just running CFLoopRunLoop would be ok. But in timer calls, Chromium relies on the fact that the message pump needs a delegate to be set, and this is done only, as far as I have seen, when explicitly running the message loop (which will in turn run the MacOS X message loop). How can I change this behavior without modifying Chromium code ? (I would like to have the least possible merge problems while updating versions of Chromium) What seemed possible to me was to directly call message loop functions DoWork, DoDelayedWork, etc. (as a delegate of the message pump). The problem is that I need an instance of a message loop, which creates anyway an instance of a message pump. But I also need to implement a message pump to be notified of works to be scheduled. So for now I'm considering to change message_loop.cc code to change MessageLoop ctor, and including my implementation of the message pump with a conditional macro as it is done for now to handle different platforms. Does anyone sees a way to do somehow the following without actually modifying chromium code ? Thanks for any suggestions or thoughts on that matter, Raphael --~--~-~--~~~---~--~~ 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: Memory usage in chrome
On Jun 21, 3:37 am, n179911 n179...@gmail.com wrote: Hi, There is a test which compares memory usage among rendering engineshttp://dotnetperls.com/chrome-memory From the site, it shows the maximum memory usage of Chrome is more than Safari is 2 times. Since both of them are Webkit base, does that mean the V8 engine uses twice as much memory as squirrel fish? --- Maximum memory used --- Peak memory usage measured during experiment. Chrome: 1216.16 MB [Largest] Firefox: 327.65 MB [Smallest] Opera: 554.11 MB Safari: 517.00 MB I find these results somewhat disingenuous. I left both Firefox and Chrome open over the weekend (both on Linux, with the Chromium daily build), Firefox with 1 tab, Chrome with 4 (one of them being Gmail). Chrome's memory usage didn't move while I had to kill Firefox for eating up 1.5GB of RAM and being generally unresponsive. Maybe Chrome uses more memory to do its job initially, but it certainly doesn't have the leaks that Firefox does which cause me to have to restart it several times a day. Keep up the awesome work, Chrome peeps. I can't wait until I'm using Chrome as my default browser on all my platforms. -- Toby DiPasquale --~--~-~--~~~---~--~~ 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: [webkit-dev] Changing our IDL syntax to get closer to WebIDL
FYI from the webkit mailing list. We'll probably want to prepare a similar CL for our binding generating code and whoever is doing the merges should look out for this change being landed. J On Sun, Jun 21, 2009 at 10:46 PM, Darin Adler da...@apple.com wrote: The IDL file format we use to generate our bindings has some things in common with WebIDL and many differences. There are extended attributes we use that exist in WebIDL but with a different name. As a first step in making our IDL syntax be as close to the WebIDL standard as possible, I’d like to move our extended attributes so they go in the appropriate place in the syntax. Ours currently come later in an attribute definition; WebIDL puts them before the attribute definition. I have a patch to do this in this bug https://bugs.webkit.org/show_bug.cgi?id=26398. Currently the patch contains the code changes to make the binding machinery parse the new syntax, and a couple hand-converted files. I plan to write a script to convert all the IDL files to the new syntax. Should be easy. Not sure about what impact this will have for V8. -- Darin ___ webkit-dev mailing list webkit-...@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev --~--~-~--~~~---~--~~ 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: Memory usage in chrome
On Mon, Jun 22, 2009 at 9:29 AM, Mike Beltzner beltz...@mozilla.com wrote: On 21-Jun-09, at 10:22 AM, Mike Belshe wrote: Second, the author is basically right. Since he's running on Vista, its a bit hard to tell whether his stats included shared memory or not; using the default memory statistic (Memory (Private Working Set)) is actually a pretty good measure to just sum. But he doesn't say which measurement he used. Doesn't Private Bytes accurately represent the private memory for a given process? I thought the whole point of that was that it didn't measure any shared memory pools. Yes, that accurately represents the private memory for a process, but it doesn't reflect the user's experience. Windows generally tracks working set. Why? Because the working set is the amount of memory *not available to other apps*. If other apps can have the memory, then using the bytes is inconsequential. For most applications, there isn't much difference between private bytes and working set private bytes. However, because of Chrome's multi-proc architecture, there is a big difference. The reason is because Chrome intentionally gives memory back to the OS. For instance, on my current instance of Chrome, I'm using 16 tabs. The sum of the private bytes is 514408. The sum of the private working set bytes is 275040, nearly half of the private bytes number. This is on a machine with 8GB of RAM, so there is plenty of memory to go around. But if some other app wants the memory, Chrome gave it back to the OS and will suffer the page faults to get it back. Since Chrome has given it back to the OS (and has volunteered to take the performance consequences of getting it back), I don't think it should be counted as Chrome usage. Others may disagree. But Windows uses working set as the primary metric for all applications the OS folks agree that working set is the right way to account for memory usage. Single process browsers have a hard time giving memory back, because they can't differentiate which pages are accounted to unused, background tabs and which pages are accounted to the active, in-use tabs. Finally, the common metric which definitely doesn't work well is Windows XP's default metric: working set (private + shared). Because of shared memory between processes, simply summing the working set will far overstate the actual RAM used. Part of the motivation with Vista changing the default metric from working set to private working set was precisely to deal with the issue of better accounting of shared memory. Mike --~--~-~--~~~---~--~~ 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: Pixel layout tests and checksums
Since I'm waiting for a build I sat down to implement this. But our image checksums are not checksums of the image files :(, but rather checksums of the pixels stored in the image. And Tony points out that our image checksumming is completely insane: = // Fix the alpha. The expected PNGs on Mac have an alpha channel, so we want // to keep it. On Windows, the alpha channel is wrong since text/form control // drawing may have erased it in a few places. So on Windows we force it to // opaque and also don't write the alpha channel for the reference. Linux // doesn't have the wrong alpha like Windows, but we ignore it anyway. #if defined(OS_WIN) bool discard_transparency = true; device-makeOpaque(0, 0, src_bmp.width(), src_bmp.height()); #elif defined(OS_LINUX) bool discard_transparency = true; #elif defined(OS_MACOSX) bool discard_transparency = false; #endif // Compute MD5 sum. We should have done this before calling // device-makeOpaque on Windows. Because we do it after the call, there are // some images that are the pixel identical on windows and other platforms // but have different MD5 sums. At this point, rebaselining all the windows // tests is too much of a pain, so we just check in different baselines. To be more clear, here's a table of the platforms and their behaviors. O=opaque, T=transparent. (Sorry for my ghetto proportionally-spaced table here.) Win Mac Lin cksumO T T pngO T O I conclude that on Linux, you cannot go from the PNG file back to the checksum in the presence of alpha. Just for fun I played around a bit with commands like: convert path/to/pngfile rgba:- | md5sum and wasn't able to repro the checksums I'm seeing. It looks ok from convert path/to/pngfile rgba:- | xxd -g4 (the RGBA-BGRA problem doesn't apply for this black and while png file...). In summary: tears. On Mon, Jun 22, 2009 at 3:20 AM, Dean McNameede...@chromium.org wrote: Last week I updated our DEPS to pull in a newer version of Skia. I was stumped at a few cases where the checked in PNG looked completely wrong, but yet it was passing on the buildbots. There was no way that image could have been the output. It just dawned on me today, but I haven't verified it. I can dig up my commit to verify it, but I'd say 99% sure this was the case. If the checksum is valid, we don't even go to the PNG. Therefor I believe we have a bunch of layout tests where the checked in PNG is completely wrong, but the checksum is right. I don't have the time right now, but it would be great if someone could write a script and clean this up. Thanks -- dean --~--~-~--~~~---~--~~ 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: Error While compiling on ubuntu 64bit
You need to give more info. What revision of the source code are you at? Did you make any local changes? FWIW, we have a Jaunty build bot on the experimental waterfall and it built ok. http://build.chromium.org/buildbot/waterfall.fyi/builders/Chromium%20Linux%20(Jaunty)/builds/1981 On Mon, Jun 22, 2009 at 5:00 AM, Ibrar Ahmedibrar.ah...@gmail.com wrote: Hi, I am getting error while compiling on ubuntu 9.04 (64bit) /home/ibrar/Google/chromium/src/third_party/WebKit/WebCore/css/CSSParser.cpp: In function 'int WebCore::cssValueKeywordID(const WebCore::CSSParserString)': /home/ibrar/Google/chromium/src/third_party/WebKit/WebCore/css/CSSParser.cpp:4947: error: expected initializer before '*' token /home/ibrar/Google/chromium/src/third_party/WebKit/WebCore/css/CSSParser.cpp:4948: error: 'hashTableEntry' was not declared in this scope Compiling /home/ibrar/Google/chromium/src/sconsbuild/Debug/obj/third_party/WebKit/WebCore/css/CSSPropertyLonghand.o scons: *** [/home/ibrar/Google/chromium/src/sconsbuild/Debug/obj/third_party/WebKit/WebCore/css/CSSParser.o] Error 1 scons: building terminated because of errors. On Sat, Jun 20, 2009 at 4:45 AM, Hunnter2k3 hunn...@gmail.com wrote: Ever since V2 has been pushed, the CPU usage for Chrome has sky- rocketed every time i am loading pages. Every time a page is loading, both cores are hitting 100%. Worse is when sites are lagging or slow, the CPU is still at 100% until it is finished, no ifs or buts. I even done a fresh install, I even installed SRWare's Iron, it still hits 100% when a page loads. If this is what V2 is going to be like, i am going straight back to V1, i don't want a browser eating 100% and interrupting other processes, especially if it is because of a feature i couldn't care less about. Is this what has happened to Full Page Zoom now, instead of generating it each time a person wants to zoom? If so, for the love of everything decent, please go back to the old system, i don't care for FPZ and never will, or at least start using that wonderful thing called Options and add it in there, please. -- Ibrar Ahmed --~--~-~--~~~---~--~~ 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: [webkit-dev] Changing our IDL syntax to get closer to WebIDL
If our binding code is already upstream by then, Darin may be able to keep Chromium building throughout the process. https://bugs.webkit.org/show_bug.cgi?id=26567 On Mon, Jun 22, 2009 at 9:53 AM, Jeremy Orlowjor...@chromium.org wrote: FYI from the webkit mailing list. We'll probably want to prepare a similar CL for our binding generating code and whoever is doing the merges should look out for this change being landed. J On Sun, Jun 21, 2009 at 10:46 PM, Darin Adler da...@apple.com wrote: The IDL file format we use to generate our bindings has some things in common with WebIDL and many differences. There are extended attributes we use that exist in WebIDL but with a different name. As a first step in making our IDL syntax be as close to the WebIDL standard as possible, I’d like to move our extended attributes so they go in the appropriate place in the syntax. Ours currently come later in an attribute definition; WebIDL puts them before the attribute definition. I have a patch to do this in this bug https://bugs.webkit.org/show_bug.cgi?id=26398. Currently the patch contains the code changes to make the binding machinery parse the new syntax, and a couple hand-converted files. I plan to write a script to convert all the IDL files to the new syntax. Should be easy. Not sure about what impact this will have for V8. -- Darin ___ webkit-dev mailing list webkit-...@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev --~--~-~--~~~---~--~~ 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: Pixel layout tests and checksums
I noticed this too. LayoutTests/fast/transforms/matrix-02.html has been marked fail for a while on Linux because the checksum is different from Windows, even though the output pngs are identical. On Mon, Jun 22, 2009 at 10:24 AM, Evan Martine...@chromium.org wrote: Since I'm waiting for a build I sat down to implement this. But our image checksums are not checksums of the image files :(, but rather checksums of the pixels stored in the image. And Tony points out that our image checksumming is completely insane: = // Fix the alpha. The expected PNGs on Mac have an alpha channel, so we want // to keep it. On Windows, the alpha channel is wrong since text/form control // drawing may have erased it in a few places. So on Windows we force it to // opaque and also don't write the alpha channel for the reference. Linux // doesn't have the wrong alpha like Windows, but we ignore it anyway. #if defined(OS_WIN) bool discard_transparency = true; device-makeOpaque(0, 0, src_bmp.width(), src_bmp.height()); #elif defined(OS_LINUX) bool discard_transparency = true; #elif defined(OS_MACOSX) bool discard_transparency = false; #endif // Compute MD5 sum. We should have done this before calling // device-makeOpaque on Windows. Because we do it after the call, there are // some images that are the pixel identical on windows and other platforms // but have different MD5 sums. At this point, rebaselining all the windows // tests is too much of a pain, so we just check in different baselines. To be more clear, here's a table of the platforms and their behaviors. O=opaque, T=transparent. (Sorry for my ghetto proportionally-spaced table here.) Win Mac Lin cksum O T T png O T O I conclude that on Linux, you cannot go from the PNG file back to the checksum in the presence of alpha. Just for fun I played around a bit with commands like: convert path/to/pngfile rgba:- | md5sum and wasn't able to repro the checksums I'm seeing. It looks ok from convert path/to/pngfile rgba:- | xxd -g4 (the RGBA-BGRA problem doesn't apply for this black and while png file...). In summary: tears. On Mon, Jun 22, 2009 at 3:20 AM, Dean McNameede...@chromium.org wrote: Last week I updated our DEPS to pull in a newer version of Skia. I was stumped at a few cases where the checked in PNG looked completely wrong, but yet it was passing on the buildbots. There was no way that image could have been the output. It just dawned on me today, but I haven't verified it. I can dig up my commit to verify it, but I'd say 99% sure this was the case. If the checksum is valid, we don't even go to the PNG. Therefor I believe we have a bunch of layout tests where the checked in PNG is completely wrong, but the checksum is right. I don't have the time right now, but it would be great if someone could write a script and clean this up. Thanks -- dean --~--~-~--~~~---~--~~ 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: [webkit-dev] Changing our IDL syntax to get closer to WebIDL
I'm not so sure [1]but we can ask. J [1] http://lists.macosforge.org/pipermail/webkit-dev/2009-May/007960.html http://lists.macosforge.org/pipermail/webkit-dev/2009-May/007960.html1) We weren't super enthusiastic about the master WebKit tree trying to support two different JavaScript engines. But we finally agreed when the Chrome folks said this was a hard requirement to merge, and promised they would take on absolutely 100% of the maintenance burden and impose no cost on the rest of the WebKit project. As a result: On Mon, Jun 22, 2009 at 10:48 AM, Eric Seidel esei...@chromium.org wrote: If our binding code is already upstream by then, Darin may be able to keep Chromium building throughout the process. https://bugs.webkit.org/show_bug.cgi?id=26567 On Mon, Jun 22, 2009 at 9:53 AM, Jeremy Orlowjor...@chromium.org wrote: FYI from the webkit mailing list. We'll probably want to prepare a similar CL for our binding generating code and whoever is doing the merges should look out for this change being landed. J On Sun, Jun 21, 2009 at 10:46 PM, Darin Adler da...@apple.com wrote: The IDL file format we use to generate our bindings has some things in common with WebIDL and many differences. There are extended attributes we use that exist in WebIDL but with a different name. As a first step in making our IDL syntax be as close to the WebIDL standard as possible, I’d like to move our extended attributes so they go in the appropriate place in the syntax. Ours currently come later in an attribute definition; WebIDL puts them before the attribute definition. I have a patch to do this in this bug https://bugs.webkit.org/show_bug.cgi?id=26398. Currently the patch contains the code changes to make the binding machinery parse the new syntax, and a couple hand-converted files. I plan to write a script to convert all the IDL files to the new syntax. Should be easy. Not sure about what impact this will have for V8. -- Darin ___ webkit-dev mailing list webkit-...@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev --~--~-~--~~~---~--~~ 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: Pixel layout tests and checksums
Just so I'm not all negative, my suggestions after consulting with Tony: 1) Make Linux behavior match Windows, ignoring the recommendation in the comments below. 2) Rebaseline everything on Linux. :( 3) Now converting from a PNG file to expected output is easy on all three platforms: convert input.png rgba:- | swizzle_rgba_to_bgra | md5sum (Not certain if Mac uses BGRA images, though.) On Mon, Jun 22, 2009 at 10:24 AM, Evan Martine...@chromium.org wrote: Since I'm waiting for a build I sat down to implement this. But our image checksums are not checksums of the image files :(, but rather checksums of the pixels stored in the image. And Tony points out that our image checksumming is completely insane: = // Fix the alpha. The expected PNGs on Mac have an alpha channel, so we want // to keep it. On Windows, the alpha channel is wrong since text/form control // drawing may have erased it in a few places. So on Windows we force it to // opaque and also don't write the alpha channel for the reference. Linux // doesn't have the wrong alpha like Windows, but we ignore it anyway. #if defined(OS_WIN) bool discard_transparency = true; device-makeOpaque(0, 0, src_bmp.width(), src_bmp.height()); #elif defined(OS_LINUX) bool discard_transparency = true; #elif defined(OS_MACOSX) bool discard_transparency = false; #endif // Compute MD5 sum. We should have done this before calling // device-makeOpaque on Windows. Because we do it after the call, there are // some images that are the pixel identical on windows and other platforms // but have different MD5 sums. At this point, rebaselining all the windows // tests is too much of a pain, so we just check in different baselines. To be more clear, here's a table of the platforms and their behaviors. O=opaque, T=transparent. (Sorry for my ghetto proportionally-spaced table here.) Win Mac Lin cksum O T T png O T O I conclude that on Linux, you cannot go from the PNG file back to the checksum in the presence of alpha. Just for fun I played around a bit with commands like: convert path/to/pngfile rgba:- | md5sum and wasn't able to repro the checksums I'm seeing. It looks ok from convert path/to/pngfile rgba:- | xxd -g4 (the RGBA-BGRA problem doesn't apply for this black and while png file...). In summary: tears. On Mon, Jun 22, 2009 at 3:20 AM, Dean McNameede...@chromium.org wrote: Last week I updated our DEPS to pull in a newer version of Skia. I was stumped at a few cases where the checked in PNG looked completely wrong, but yet it was passing on the buildbots. There was no way that image could have been the output. It just dawned on me today, but I haven't verified it. I can dig up my commit to verify it, but I'd say 99% sure this was the case. If the checksum is valid, we don't even go to the PNG. Therefor I believe we have a bunch of layout tests where the checked in PNG is completely wrong, but the checksum is right. I don't have the time right now, but it would be great if someone could write a script and clean this up. Thanks -- dean --~--~-~--~~~---~--~~ 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: [webkit-dev] Changing our IDL syntax to get closer to WebIDL
I'm still not enthused about WebKit having 2 different JavaScript engines. ;) But that's a discussion for another time... -eric On Mon, Jun 22, 2009 at 10:54 AM, Jeremy Orlowjor...@chromium.org wrote: I'm not so sure [1]but we can ask. J [1] http://lists.macosforge.org/pipermail/webkit-dev/2009-May/007960.html 1) We weren't super enthusiastic about the master WebKit tree trying to support two different JavaScript engines. But we finally agreed when the Chrome folks said this was a hard requirement to merge, and promised they would take on absolutely 100% of the maintenance burden and impose no cost on the rest of the WebKit project. As a result: On Mon, Jun 22, 2009 at 10:48 AM, Eric Seidel esei...@chromium.org wrote: If our binding code is already upstream by then, Darin may be able to keep Chromium building throughout the process. https://bugs.webkit.org/show_bug.cgi?id=26567 On Mon, Jun 22, 2009 at 9:53 AM, Jeremy Orlowjor...@chromium.org wrote: FYI from the webkit mailing list. We'll probably want to prepare a similar CL for our binding generating code and whoever is doing the merges should look out for this change being landed. J On Sun, Jun 21, 2009 at 10:46 PM, Darin Adler da...@apple.com wrote: The IDL file format we use to generate our bindings has some things in common with WebIDL and many differences. There are extended attributes we use that exist in WebIDL but with a different name. As a first step in making our IDL syntax be as close to the WebIDL standard as possible, I’d like to move our extended attributes so they go in the appropriate place in the syntax. Ours currently come later in an attribute definition; WebIDL puts them before the attribute definition. I have a patch to do this in this bug https://bugs.webkit.org/show_bug.cgi?id=26398. Currently the patch contains the code changes to make the binding machinery parse the new syntax, and a couple hand-converted files. I plan to write a script to convert all the IDL files to the new syntax. Should be easy. Not sure about what impact this will have for V8. -- Darin ___ webkit-dev mailing list webkit-...@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev --~--~-~--~~~---~--~~ 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: Pixel layout tests and checksums
This isn't the best, but it would be easy to add a flag to run-webkit-tests that told it to always do the pixel comparison even if the checksums matched. Ojan On Mon, Jun 22, 2009 at 10:55 AM, Evan Martin e...@chromium.org wrote: Just so I'm not all negative, my suggestions after consulting with Tony: 1) Make Linux behavior match Windows, ignoring the recommendation in the comments below. 2) Rebaseline everything on Linux. :( 3) Now converting from a PNG file to expected output is easy on all three platforms: convert input.png rgba:- | swizzle_rgba_to_bgra | md5sum (Not certain if Mac uses BGRA images, though.) On Mon, Jun 22, 2009 at 10:24 AM, Evan Martine...@chromium.org wrote: Since I'm waiting for a build I sat down to implement this. But our image checksums are not checksums of the image files :(, but rather checksums of the pixels stored in the image. And Tony points out that our image checksumming is completely insane: = // Fix the alpha. The expected PNGs on Mac have an alpha channel, so we want // to keep it. On Windows, the alpha channel is wrong since text/form control // drawing may have erased it in a few places. So on Windows we force it to // opaque and also don't write the alpha channel for the reference. Linux // doesn't have the wrong alpha like Windows, but we ignore it anyway. #if defined(OS_WIN) bool discard_transparency = true; device-makeOpaque(0, 0, src_bmp.width(), src_bmp.height()); #elif defined(OS_LINUX) bool discard_transparency = true; #elif defined(OS_MACOSX) bool discard_transparency = false; #endif // Compute MD5 sum. We should have done this before calling // device-makeOpaque on Windows. Because we do it after the call, there are // some images that are the pixel identical on windows and other platforms // but have different MD5 sums. At this point, rebaselining all the windows // tests is too much of a pain, so we just check in different baselines. To be more clear, here's a table of the platforms and their behaviors. O=opaque, T=transparent. (Sorry for my ghetto proportionally-spaced table here.) Win Mac Lin cksumO T T pngO T O I conclude that on Linux, you cannot go from the PNG file back to the checksum in the presence of alpha. Just for fun I played around a bit with commands like: convert path/to/pngfile rgba:- | md5sum and wasn't able to repro the checksums I'm seeing. It looks ok from convert path/to/pngfile rgba:- | xxd -g4 (the RGBA-BGRA problem doesn't apply for this black and while png file...). In summary: tears. On Mon, Jun 22, 2009 at 3:20 AM, Dean McNameede...@chromium.org wrote: Last week I updated our DEPS to pull in a newer version of Skia. I was stumped at a few cases where the checked in PNG looked completely wrong, but yet it was passing on the buildbots. There was no way that image could have been the output. It just dawned on me today, but I haven't verified it. I can dig up my commit to verify it, but I'd say 99% sure this was the case. If the checksum is valid, we don't even go to the PNG. Therefor I believe we have a bunch of layout tests where the checked in PNG is completely wrong, but the checksum is right. I don't have the time right now, but it would be great if someone could write a script and clean this up. Thanks -- dean --~--~-~--~~~---~--~~ 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: Pixel layout tests and checksums
How about just running the pixel comparison only when the checksums don't match? Still not ideal, of course. -Greg. On Mon, Jun 22, 2009 at 11:30 AM, Ojan Vafai o...@chromium.org wrote: This isn't the best, but it would be easy to add a flag to run-webkit-tests that told it to always do the pixel comparison even if the checksums matched. Ojan On Mon, Jun 22, 2009 at 10:55 AM, Evan Martin e...@chromium.org wrote: Just so I'm not all negative, my suggestions after consulting with Tony: 1) Make Linux behavior match Windows, ignoring the recommendation in the comments below. 2) Rebaseline everything on Linux. :( 3) Now converting from a PNG file to expected output is easy on all three platforms: convert input.png rgba:- | swizzle_rgba_to_bgra | md5sum (Not certain if Mac uses BGRA images, though.) On Mon, Jun 22, 2009 at 10:24 AM, Evan Martine...@chromium.org wrote: Since I'm waiting for a build I sat down to implement this. But our image checksums are not checksums of the image files :(, but rather checksums of the pixels stored in the image. And Tony points out that our image checksumming is completely insane: = // Fix the alpha. The expected PNGs on Mac have an alpha channel, so we want // to keep it. On Windows, the alpha channel is wrong since text/form control // drawing may have erased it in a few places. So on Windows we force it to // opaque and also don't write the alpha channel for the reference. Linux // doesn't have the wrong alpha like Windows, but we ignore it anyway. #if defined(OS_WIN) bool discard_transparency = true; device-makeOpaque(0, 0, src_bmp.width(), src_bmp.height()); #elif defined(OS_LINUX) bool discard_transparency = true; #elif defined(OS_MACOSX) bool discard_transparency = false; #endif // Compute MD5 sum. We should have done this before calling // device-makeOpaque on Windows. Because we do it after the call, there are // some images that are the pixel identical on windows and other platforms // but have different MD5 sums. At this point, rebaselining all the windows // tests is too much of a pain, so we just check in different baselines. To be more clear, here's a table of the platforms and their behaviors. O=opaque, T=transparent. (Sorry for my ghetto proportionally-spaced table here.) Win Mac Lin cksumO T T pngO T O I conclude that on Linux, you cannot go from the PNG file back to the checksum in the presence of alpha. Just for fun I played around a bit with commands like: convert path/to/pngfile rgba:- | md5sum and wasn't able to repro the checksums I'm seeing. It looks ok from convert path/to/pngfile rgba:- | xxd -g4 (the RGBA-BGRA problem doesn't apply for this black and while png file...). In summary: tears. On Mon, Jun 22, 2009 at 3:20 AM, Dean McNameede...@chromium.org wrote: Last week I updated our DEPS to pull in a newer version of Skia. I was stumped at a few cases where the checked in PNG looked completely wrong, but yet it was passing on the buildbots. There was no way that image could have been the output. It just dawned on me today, but I haven't verified it. I can dig up my commit to verify it, but I'd say 99% sure this was the case. If the checksum is valid, we don't even go to the PNG. Therefor I believe we have a bunch of layout tests where the checked in PNG is completely wrong, but the checksum is right. I don't have the time right now, but it would be great if someone could write a script and clean this up. Thanks -- dean --~--~-~--~~~---~--~~ 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: Pixel layout tests and checksums
That's what we do now. It sounds like someone checked in new checksums without their corresponding new images, though, so the tests pass even though the nominally expected PNGs are wrong. - Pam On Mon, Jun 22, 2009 at 11:40 AM, Greg Spencer gspen...@google.com wrote: How about just running the pixel comparison only when the checksums don't match? Still not ideal, of course. -Greg. On Mon, Jun 22, 2009 at 11:30 AM, Ojan Vafai o...@chromium.org wrote: This isn't the best, but it would be easy to add a flag to run-webkit-tests that told it to always do the pixel comparison even if the checksums matched. Ojan On Mon, Jun 22, 2009 at 10:55 AM, Evan Martin e...@chromium.org wrote: Just so I'm not all negative, my suggestions after consulting with Tony: 1) Make Linux behavior match Windows, ignoring the recommendation in the comments below. 2) Rebaseline everything on Linux. :( 3) Now converting from a PNG file to expected output is easy on all three platforms: convert input.png rgba:- | swizzle_rgba_to_bgra | md5sum (Not certain if Mac uses BGRA images, though.) On Mon, Jun 22, 2009 at 10:24 AM, Evan Martine...@chromium.org wrote: Since I'm waiting for a build I sat down to implement this. But our image checksums are not checksums of the image files :(, but rather checksums of the pixels stored in the image. And Tony points out that our image checksumming is completely insane: = // Fix the alpha. The expected PNGs on Mac have an alpha channel, so we want // to keep it. On Windows, the alpha channel is wrong since text/form control // drawing may have erased it in a few places. So on Windows we force it to // opaque and also don't write the alpha channel for the reference. Linux // doesn't have the wrong alpha like Windows, but we ignore it anyway. #if defined(OS_WIN) bool discard_transparency = true; device-makeOpaque(0, 0, src_bmp.width(), src_bmp.height()); #elif defined(OS_LINUX) bool discard_transparency = true; #elif defined(OS_MACOSX) bool discard_transparency = false; #endif // Compute MD5 sum. We should have done this before calling // device-makeOpaque on Windows. Because we do it after the call, there are // some images that are the pixel identical on windows and other platforms // but have different MD5 sums. At this point, rebaselining all the windows // tests is too much of a pain, so we just check in different baselines. To be more clear, here's a table of the platforms and their behaviors. O=opaque, T=transparent. (Sorry for my ghetto proportionally-spaced table here.) Win Mac Lin cksumO T T pngO T O I conclude that on Linux, you cannot go from the PNG file back to the checksum in the presence of alpha. Just for fun I played around a bit with commands like: convert path/to/pngfile rgba:- | md5sum and wasn't able to repro the checksums I'm seeing. It looks ok from convert path/to/pngfile rgba:- | xxd -g4 (the RGBA-BGRA problem doesn't apply for this black and while png file...). In summary: tears. On Mon, Jun 22, 2009 at 3:20 AM, Dean McNameede...@chromium.org wrote: Last week I updated our DEPS to pull in a newer version of Skia. I was stumped at a few cases where the checked in PNG looked completely wrong, but yet it was passing on the buildbots. There was no way that image could have been the output. It just dawned on me today, but I haven't verified it. I can dig up my commit to verify it, but I'd say 99% sure this was the case. If the checksum is valid, we don't even go to the PNG. Therefor I believe we have a bunch of layout tests where the checked in PNG is completely wrong, but the checksum is right. I don't have the time right now, but it would be great if someone could write a script and clean this up. Thanks -- dean --~--~-~--~~~---~--~~ 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: [webkit-dev] Changing our IDL syntax to get closer to WebIDL
Amen. I am working on it :) First step -- teach our code generator to understand IDL in the same way JSC does. :DG On Mon, Jun 22, 2009 at 12:02 PM, Aaron Boodmana...@chromium.org wrote: One thing I'd really like to see is a reduction in the amount of custom bindings code. I am terrified by the number of subtle bugs that must be hiding in there. It seems like teaching the IDL parser and code generator on the WebKit side about more WebIDL-isms would help with this, since a lot of the custom bindings deal with things like function references. - a On Mon, Jun 22, 2009 at 11:25 AM, Eric Seidelesei...@chromium.org wrote: I'm still not enthused about WebKit having 2 different JavaScript engines. ;) But that's a discussion for another time... -eric On Mon, Jun 22, 2009 at 10:54 AM, Jeremy Orlowjor...@chromium.org wrote: I'm not so sure [1]but we can ask. J [1] http://lists.macosforge.org/pipermail/webkit-dev/2009-May/007960.html 1) We weren't super enthusiastic about the master WebKit tree trying to support two different JavaScript engines. But we finally agreed when the Chrome folks said this was a hard requirement to merge, and promised they would take on absolutely 100% of the maintenance burden and impose no cost on the rest of the WebKit project. As a result: On Mon, Jun 22, 2009 at 10:48 AM, Eric Seidel esei...@chromium.org wrote: If our binding code is already upstream by then, Darin may be able to keep Chromium building throughout the process. https://bugs.webkit.org/show_bug.cgi?id=26567 On Mon, Jun 22, 2009 at 9:53 AM, Jeremy Orlowjor...@chromium.org wrote: FYI from the webkit mailing list. We'll probably want to prepare a similar CL for our binding generating code and whoever is doing the merges should look out for this change being landed. J On Sun, Jun 21, 2009 at 10:46 PM, Darin Adler da...@apple.com wrote: The IDL file format we use to generate our bindings has some things in common with WebIDL and many differences. There are extended attributes we use that exist in WebIDL but with a different name. As a first step in making our IDL syntax be as close to the WebIDL standard as possible, I’d like to move our extended attributes so they go in the appropriate place in the syntax. Ours currently come later in an attribute definition; WebIDL puts them before the attribute definition. I have a patch to do this in this bug https://bugs.webkit.org/show_bug.cgi?id=26398. Currently the patch contains the code changes to make the binding machinery parse the new syntax, and a couple hand-converted files. I plan to write a script to convert all the IDL files to the new syntax. Should be easy. Not sure about what impact this will have for V8. -- Darin ___ webkit-dev mailing list webkit-...@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev --~--~-~--~~~---~--~~ 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: [webkit-dev] Changing our IDL syntax to get closer to WebIDL
I agree. I was thinking about looking into this (once LocalStorage is working). Besides the fact that we have more custom code than we should have, a good portion of the .dll is just generated code. It seems like we should be able to strike a better balance of doing things dynamically vs statically in the binding code. J On Mon, Jun 22, 2009 at 12:02 PM, Aaron Boodman a...@chromium.org wrote: One thing I'd really like to see is a reduction in the amount of custom bindings code. I am terrified by the number of subtle bugs that must be hiding in there. It seems like teaching the IDL parser and code generator on the WebKit side about more WebIDL-isms would help with this, since a lot of the custom bindings deal with things like function references. - a On Mon, Jun 22, 2009 at 11:25 AM, Eric Seidelesei...@chromium.org wrote: I'm still not enthused about WebKit having 2 different JavaScript engines. ;) But that's a discussion for another time... -eric On Mon, Jun 22, 2009 at 10:54 AM, Jeremy Orlowjor...@chromium.org wrote: I'm not so sure [1]but we can ask. J [1] http://lists.macosforge.org/pipermail/webkit-dev/2009-May/007960.html 1) We weren't super enthusiastic about the master WebKit tree trying to support two different JavaScript engines. But we finally agreed when the Chrome folks said this was a hard requirement to merge, and promised they would take on absolutely 100% of the maintenance burden and impose no cost on the rest of the WebKit project. As a result: On Mon, Jun 22, 2009 at 10:48 AM, Eric Seidel esei...@chromium.org wrote: If our binding code is already upstream by then, Darin may be able to keep Chromium building throughout the process. https://bugs.webkit.org/show_bug.cgi?id=26567 On Mon, Jun 22, 2009 at 9:53 AM, Jeremy Orlowjor...@chromium.org wrote: FYI from the webkit mailing list. We'll probably want to prepare a similar CL for our binding generating code and whoever is doing the merges should look out for this change being landed. J On Sun, Jun 21, 2009 at 10:46 PM, Darin Adler da...@apple.com wrote: The IDL file format we use to generate our bindings has some things in common with WebIDL and many differences. There are extended attributes we use that exist in WebIDL but with a different name. As a first step in making our IDL syntax be as close to the WebIDL standard as possible, I’d like to move our extended attributes so they go in the appropriate place in the syntax. Ours currently come later in an attribute definition; WebIDL puts them before the attribute definition. I have a patch to do this in this bug https://bugs.webkit.org/show_bug.cgi?id=26398. Currently the patch contains the code changes to make the binding machinery parse the new syntax, and a couple hand-converted files. I plan to write a script to convert all the IDL files to the new syntax. Should be easy. Not sure about what impact this will have for V8. -- Darin ___ webkit-dev mailing list webkit-...@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] about gtest's main in chromium
Hi, I think there're two ways to start GTest test cases: writing a main by myself or linking a gtest_main.lib. But I find something weird in the chromiun's GTest projects, they neither write a main nor link a gtest_main.lib. How do they start GTest? --~--~-~--~~~---~--~~ 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: about gtest's main in chromium
On Mon, Jun 22, 2009 at 7:55 PM, Jickae Davisjick...@gmail.com wrote: But I find something weird in the chromiun's GTest projects, they neither write a main nor link a gtest_main.lib. How do they start GTest? Well, you can always set a breakpoint at main and see where you end up. For base_unittests, it's base/run_all_unittests.cc for example. 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] layout test can't run
nbsp;I've changed the .gclient, and downloaded the layout tests.But I can't run it, it just always give me a msg back: nbsp; ### ## Layout test system dependencies check failed. ## Some layout tests may fail due to unexpected theme. ## ## To fix, go to Display Properties - Appearance, and select: ##nbsp; + Windows and buttons: Windows XP style ##nbsp; + Color scheme: Default (blue) ##nbsp; + Font size: Normal ### nbsp; I've done these 3 instructions,nbsp;had all fonts installed already, and still get the msg, why? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Important: Porting bits of UI by subclassing is now banned.
Porting bits of UI like dialog boxes by creating a platform-independent base class and subclassing for each platform is now no longer allowed. In C++, inheritance is something to be used carefully. You should create a subclass only when the derived class is a logical specialization. That one class contains cross platform state for a bit of UI and another class contains that platform-specific UI does not mean that the latter is a logical specialization of the former. Overuse of inheritance makes the code harder to follow and understand, and Brett and I in particular have spent a lot of time over the past few months correcting this throughout the Chrome front end. If you are creating UI on another platform and want to reuse common code, please move the common code into a separate object that the platform specific UI owns. This applies to changes you're currently working on, too. e.g., I just redid the Task Manager to fit this pattern. There are two frontends for it currently, TaskManagerView (windows) and TaskManagerGtk (linux). Both have a TaskManager object that they use to populate themselves. It is always more convenient for native code in a particular frontend to directly create its own UI components, rather than having to go through a factory method. If you need any advice on the feature you're working on, please let me know. I'm more than happy to discuss. We should also correct existing instances of the undesirable pattern soon. As I discover them, I'll be emailing the people responsible. If you know of any, please let me know. -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: Important: Porting bits of UI by subclassing is now banned.
On Mon, Jun 22, 2009 at 10:22 PM, Ben Goodger (Google) b...@chromium.orgwrote: If you are creating UI on another platform and want to reuse common code, please move the common code into a separate object that the platform specific UI owns. Note that this is a specific application of a general good-C++-coding principle: prefer composition to inheritance. Ignore this at your peril, or like me you may end up forced to rewrite big chunks of your code when you later realize that inheritance does not extend to some future change you wanted to make nearly as flexibly as composition would have. (For the curious, this is why I spent the last week rewriting the cross-platform WebKit ICO and BMP decoders I just checked in.) PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
