using this bug as a kitchen-sink for several QtLauncher requests :) These would help perform proper testing of AC and other graphics features on Symbian and other embedded platforms. 1. Showing FPS somewhere on screen, perhaps an overlay QGraphicsTextItem 2. Full screen browsing: remove the menus completely until some (specific) key / mouse area is pressed 3. Toggle viewport update-mode 4. Toggle scrollbars 5. graphics backend mode: GL graphicssystem, full raster, or raster with a QGLWidget on the viewport
(In reply to comment #0) > 2. Full screen browsing: remove the menus completely until some (specific) key > / mouse area is pressed Any ideas about which key / mouse area to use? I'm not used to test WebKit on Symbian, so I don't know the use and test cases. > 5. graphics backend mode: GL graphicssystem, full raster, or raster with a > QGLWidget on the viewport Using command line arguments, right?
(In reply to comment #1) > (In reply to comment #0) > > 2. Full screen browsing: remove the menus completely until some (specific) key > > / mouse area is pressed > How about doing something like the N97 browser: - put a button in the right-bottom corner of the screen - if inactive for a while, the QtLauncher "UI" disappears, and only that button stays - pushing the button again gets the QtLauncher UI back. > Any ideas about which key / mouse area to use? > I'm not used to test WebKit on Symbian, so I don't know the use and test cases. > > > 5. graphics backend mode: GL graphicssystem, full raster, or raster with a > > QGLWidget on the viewport > > Using command line arguments, right? Yes, though I'd rather if everything was configurable from the screen. I think switching between a regular viewport and a QGLWidget viewport can be done in runtime. Another option is to just make sure that QtLauncher runs with the right settings on Symbian.
Please follow the QtWebKit bug reporting guidelines when reporting bugs. See http://trac.webkit.org/wiki/QtWebKitBugs Specifically: - The 'QtWebKit' component should be used for bugs/features in the public QtWebKit API layer, not to signify that the bug is specific to the Qt port of WebKit http://trac.webkit.org/wiki/QtWebKitBugs#Component
> 1. Showing FPS somewhere on screen, perhaps an overlay QGraphicsTextItem > 3. Toggle viewport update-mode Those two are really related to benchmarking. Do we really want to put that kind of feature on QtLauncher? For me, the FPS should be measured by the benchmarks so we have accurate numbers. I don't want to see report about "QtLauncher running at about 10FPS". The best viewport update-mode is application specific, it should be determined by benchmarks and set once for QtLauncher. > 5. graphics backend mode: GL graphicssystem, full raster, or raster with a QGLWidget on the viewport For me, this is also mainly a benchmarking problem, not a problem of QtLauncher. Those options are justified though because of the interaction between the backend and WebGL. I would prefer a test case for this.
(In reply to comment #4) > Those two are really related to benchmarking. Do we really want to put that > kind of feature on QtLauncher? > > For me, the FPS should be measured by the benchmarks so we have accurate > numbers. I don't want to see report about "QtLauncher running at about 10FPS". > > The best viewport update-mode is application specific, it should be determined > by benchmarks and set once for QtLauncher. > For me, this is also mainly a benchmarking problem, not a problem of > QtLauncher. > Those options are justified though because of the interaction between the > backend and WebGL. > I would prefer a test case for this. From our experience of mobile applications development I'd say that sometimes you _really_ need to see the impact of changing such options. Having a convenient way of testing it on devices can help a lot. IMHO, QtLauncher is not a browser. It's a developer tool with a "Develop" menu being filled with "develop/test options". I really don't see the problem of having such features there, so all (Nokia) developers can easily test changes on different mobile devices just out-of-the-box, by installing QtWebKit+QtLauncher packages.
(In reply to comment #5) > IMHO, QtLauncher is not a browser. It's a developer tool with a "Develop" menu > being filled with "develop/test options". I really don't see the problem of > having such features there, so all (Nokia) developers can easily test changes > on different mobile devices just out-of-the-box, by installing > QtWebKit+QtLauncher packages. That is exactly my point. I don't see how those options affect the work of webkit developers. Changes in viewport update-mode, or graphic system, do not affect WebKit in any way. I don't see why I would need to switch the viewport to test any patch. Those options affects the overall performance. Performance should be handled properly, not half-baked on top of QtLauncher.
They do affect our GraphicsLayer which is used for CSS3 transformations, animation etc when accelerated compositing is enabled.
(In reply to comment #7) > They do affect our GraphicsLayer which is used for CSS3 transformations, > animation etc when accelerated compositing is enabled. I think I mentioned I would prefer that to be covered by layout test/autotest :) If the result is different with different viewportUpdate, for me it is a bug in graphicsview, isn't it? For me, it is like adding an option in the menu to see the result of the parsing of the QUrl. Yes it affects WebKit, but we cannot test all the features of QtGui/QtCore/QtNetwork.
(In reply to comment #0) > 1. Showing FPS somewhere on screen, perhaps an overlay QGraphicsTextItem > 2. Full screen browsing: remove the menus completely until some (specific) key > / mouse area is pressed > 3. Toggle viewport update-mode > 4. Toggle scrollbars > 5. graphics backend mode: GL graphicssystem, full raster, or raster with a > QGLWidget on the viewport Noam, after b36244 (FPS info not displayed on terminal), b36270 (enable/disable QGLWidget as viewport) and b36558 (toggle Frame Flattening on/off option) have landed is there anything else you miss or can we close this bug?
I'm ok with closing this bug
Closed then :)