Re: [Pharo-dev] GPU accelerated GUI

[Ben Coman]

Hi Darrin, The other thing you can use is World > Tools > Time Profiler. Put the code in the top pane (dropping the Transcript and  milliSecondsToRun: lines). Here are my results (with loop:=1000) On Windows 7... 2233 tallies, 2237 msec. 93.0% {2081ms} SmallInteger(Integer)>>timesRepeat: 6.9% {155ms} InputEventFetcher>>eventLoop   6.9% {155ms} InputEventFetcher>>waitForInput On OSX Mavericks... 33511 tallies, 33516 msec. 92.2% {30915ms} SmallInteger(Integer)>>timesRepeat: 7.8% {2601ms} InputEventFetcher>>eventLoop   7.8% {2599ms} InputEventFetcher>>waitForInput So there seems "some" issue, but actually it doesn't slow using Pharo on Mavericks.   I'd log a Case myself, but I'm not sure how to title it. Test platforms... Model Name:    Toshiba Satellite laptop Processor Name:    AMD A10-4600, Processor Speed:    2.5 GHz Memory:    12 GB OS: Windows 7 64 bit Model Name:    Mac mini Processor Name:    Intel Core i5 Processor Speed:    2.5 GHz Memory:    4 GB OS: Mavericks cheers -ben Darrin Massena wrote: I'm learning and would love to hear ideas about how best to benchmark Smalltalk rendering. I tried this very crude test in a Workspace: loops := 100. rect := Display boundingBox. a := Time millisecondsToRun: [ loops timesRepeat: [ Display forceToScreen: rect. ]. ]. Transcript show: a / loops asFloat; cr. With a full-screen window on a current model Mac Pro with stock Pharo 3 image and VM it reports 47 ms/update. On my Surface Pro 2 (Windows 8) it is takes only 1.1 ms. I'm kind of shocked by that number in comparison. It's a lower resolution screen but still. I know full screen updates are not the norm for many applications but they're still very important. Also keep in mind this is just the low level screen update, no Morphic overhead. Ideally the display update takes less than a millisecond to leave time for all the higher level rendering. For performance assessment I'd like to have a nice Frames Per Second graph running in the corner as well as repeatable test cases matching common uses (scrolling, full updates, partial updates, empty window, densely packed grid, text editor, etc) that could be run across platforms. After that I wonder about profiling. Can accurate timed traces be done from top to bottom? I imagine it would at least get murky at the VM boundary. I also noticed logic to limit display updates to 50 times a second, presumably to minimize CPU usage. CPU usage would also be reduced by optimizing rendering but in any case I'd like to see an update rate synchronized with the video rate or faster (60 or more). That would minimize tearing and allow for no perceivable UI lag. On Mon, Jun 2, 2014 at 3:48 PM, Esteban A. Maringolo <emaring...@gmail.com> wrote: 2014-06-02 16:51 GMT-03:00 stepharo <steph...@free.fr>: > It depends what you measure. > If you measure classBrowser opening then nautilus is slower because it is > doing more stuff. If adding more features degrades performance in a human perceivable way then it's slowing down. (I mean, if slowdown is linear as extra features are added). The trade-offs might be worth it (as indeed they are). > So if you really want to help > make a benchmark showing the difference between 1.4 and 3.0 on a > **concrete** case. Without that we cannot make progress. Fair enough. I'll do so :) Next time I won't say it feels slower (but not slow) until I get an appropriate benchmark. Regards, -- Esteban.