Currently the screens are just a little too small so after creating our reftest window, it gets shrunk to 974 pixels high. It needs to be 1000 pixels high. In my testing at home, turning on Compiz lets the window be any height. This would be good because Compiz is what modern Linux users are likely to be using. However, turning on Compiz will affect performance results. Another option would be to simply change the configuration to a larger screen size. 1200 pixels high or more would be fine.
Will an increase in the screen size impact any performance tests? This would need to be changed on our reference platform and then rolled out to all of the linux builders.
We will have to test this. I might test this at the same time that I change the resolution for the 10.5 machines (either next week or the following one).
7 years ago
bug 594876 is not a FF4 blocker.I am thinking towards disabling openGL coverage for Fedora as this is not planned on getting it into FF4 and we are making no good use of our CPU usage.roc could we close this and open next year when OpenGL for Linux becomes part of GFX's plan?Does it make sense?
I'd quite like to have *some* coverage even if it's just one machine running Fedora+GL. That would help us ensure that GL on Linux doesn't get worse over time.
One question, are the test runs as they are useful in any way? I say that since the screen resolution is too small. If not, we need to change the screen resolution and AFAIK that is not part of FF4 so it has low priority on my plate. If it does have some usefulness as they are we should reduce to only one branch where at least someone would be looking at it. BTW who would be looking at it if they are permanent orange and they are hidden? We don't run in only one slave. It is all or nothing unfortunately.
We should be able to fix the permaorange this week. Once bug 596784 and 597915 land we will be at least close.
If we reach green I would be fine maintaining this unit test running until we enable OpenGL for Linux even if it is long after FF4. Nevertheless, changing the resolution on the Fedora machines would still be low priority for me as there are other FF4 blocking issues. Let's revisit this at the end of October when I am more cleared out (unless anyone from releng would like to volunteer for this).
End of October sounds reasonable.
7 years ago
6 years ago
I won't be able to work on this this quarter. To restate what is going on. * we can't currently run reftests with USE_WIDGET_LAYERS * we need to either change the screen resolution or enable compiz I believe someone in one of these bugs mentioned how we can change the screen resolution to our fedora slaves. Anyone remember/knows?
This also prevents us from reftest-ing out-of-process web content. See bug 615386.
Blocks if bug 623613 blocks.
Changing the screen size is not viable on mobile devices. On many devices the screen is never big enough to hold a 1000 px browser.
From a Fennec test run: REFTEST TEST-UNEXPECTED-FAIL | | can't drawWindow remote content REFTEST INFO | WARNING: USE_WIDGET_LAYERS disabled REFTEST INFO | drawWindow flags = DRAWWINDOW_DRAW_CARET | DRAWWINDOW_DRAW_VIEW; window size = 800,480; test browser size = 800,1000
This bug has nothing to do with mobile devices.
(In reply to comment #15) > This bug has nothing to do with mobile devices. I understand that now. Withdrawing comment 13 and comment 14 :)
But this blocks Fennec since we are depending on this for reftest testing
CC'ing Benoit for feedback on changes that might affect testing WebGL.
Karl might be able to help out here.
After talking with mfinkle on the phone I can see why this has now higher importance. Let me restate what is going on: * screen resolution increase is needed to use USE_WIDGET_LAYERS * USE_WIDGET_LAYERS is needed to: ** [fennec2.0 blocker] bug 623613 - reftest-ing out-of-process web content *** this is not specific to firefox/mobile but platform which fennec uses *** this came back to releng's plate after Feb. 3rd bug 615386 #c72 *** priority was raised today AFAICT ** [not ff4 blocker] bug 604047 - reftests with HW acceleration on Linux The two reasons that this has not yet moved ahead is two reasons: * It did not block ff4 and work that did block got higher priority over this one * I spoke with roc at the AllHands (*offline*) explaining him that it is not easy to change the screen resolution on the Linux machines compared to Windows and Mac mfinkle, cjones does this capture the importance of this bug? I need someone to volunteer to be point of contact to debug any issues for whoever end up taking this bug. I have a thread from September that contains information on why it is difficult to change the screen resolution on our Linux machines. Let me get it for you in a bug-comment-suitable-chunk-size.
Thanks! (In reply to comment #20) > mfinkle, cjones does this capture the importance of this bug? Yes, and additionally your summary matches the bug dependencies and blocking+/- history. > I need someone to volunteer to be point of contact to debug any issues for > whoever end up taking this bug. Can you be more specific about what's needed here?
(In reply to comment #20) > I have a thread from September that contains information on why it is difficult > to change the screen resolution on our Linux machines. > Let me get it for you in a bug-comment-suitable-chunk-size. When we were setting up this pool, the open source nvidia driver had no 3d and questionable 2d support. We decided to use the closed source nvidia blob. Because of the way the graphics chip is wired (the vga port presents itself internally as a DVI port iirc), it wasn't possible to just attach a resistor dongle and set the resolution in the OS. We had to write up a xorg.conf file to change the resolution. I did an experiment a little while back of setting the resolution to 1600x1200 instead of 1280x1024 but found that it did not work properly. Below is an ascii diagram in which '=' and '|' represent the real border of the screen, 'P' represents where gnome-panels were drawn and '#' represents what the window manager thought the screen was for the purposes of maximizing windows. The desktop picture was drawn for the entire screen. ============================= |PPPPPPPPPPPPPPPPPPP | |################### | |################### | |################### | |################### | |PPPPPPPPPPPPPPPPPPP | | | | | ============================= I haven't figured out what went wrong there but can try this again. I think the quickest path forward is for me to file a bug to track changing the resolution while the rest of this bug is figured out on the master side.
I think Armen is going to work on this soon, so I'm assigning to him.
Does this look good? REFTEST INFO | drawWindow flags = DRAWWINDOW_DRAW_CARET | DRAWWINDOW_DRAW_VIEW | DRAWWINDOW_USE_WIDGET_LAYERS; window size = 801,1000; test browser size = 800,1000 REFTEST INFO | drawWindow flags = DRAWWINDOW_DRAW_CARET | DRAWWINDOW_DRAW_VIEW | DRAWWINDOW_USE_WIDGET_LAYERS; window size = 801,1000; test browser size = 800,1000 I am very surprised we are only one pixel above 800.  talos-r3-fed-001 - http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1297716383.1297717797.23169.gz&fulltext=1  talos-r3-fed64-002 - http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1297714220.1297714839.9753.gz&fulltext=1 [cltbld@talos-r3-fed64-002 ~]$ DISPLAY=:0 xrandr | grep current Screen 0: minimum 800 x 600, current 1600 x 1200, maximum 1600 x 1200 [cltbld@talos-r3-fed-001 ~]$ DISPLAY=:0 xrandr | grep current Screen 0: minimum 800 x 600, current 1600 x 1200, maximum 1600 x 1200
(In reply to comment #24) > Does this look good? > > REFTEST INFO | drawWindow flags = DRAWWINDOW_DRAW_CARET | DRAWWINDOW_DRAW_VIEW > | DRAWWINDOW_USE_WIDGET_LAYERS; window size = 801,1000; test browser size = > 800,1000 Yep! > I am very surprised we are only one pixel above 800. The reftest harness creates a XUL window without any user interface except the frame in which test files are loaded. This window size is expected.
This got deployed this morning between 6-7AM PDT.