[Cuis] Curious drawing performance issue

[Phil (list)]

On Sat, 2015-08-15 at 22:55 -0400, Phil (list) wrote:
> On Sat, 2015-08-15 at 18:41 -0300, Juan Vuletich wrote:
> > On 8/15/2015 5:58 PM, Phil (list) wrote:
> > > On Sat, 2015-08-15 at 10:24 -0300, Juan Vuletich wrote:
> > >> Hi Phil,
> > >>
> > >> I won't spoil your fun, so instead of explaining the difference between
> > >> Squeak and Cuis here, I give you a suggestion: Use the profiler.
> > >>
> > > Given your comment it sounds like it's by design...
> > >
> > > OK, so I reverted to an older build to get back the process-based
> > > profiler and I can see that Cuis is doing a lot more drawing (work) than
> > > Squeak. (duh!) Unfortunately, Cuis/Squeak doesn't provide a lot of
> > > tooling to tell me what that work actually is.  What I think I see going
> > > on is that Squeak is using the old region-based damage system while Cuis
> > > appears to just be bit-blitting the entire frame each time? (I'll hold
> > > off jumping up and down for joy until I get confirmation... if that's
> > > what's going on, that is FANTASTIC!)
> > >
> > 
> > C'mon! Isn't it obvious in the profiler tree that the problem is using 
> > local coordinates and transforming them on each draw?
> > 
> 
> In the old profiler output (I went back to 2404 to get it), it didn't
> jump out at me (the bounds related calls only appear to be <10% of the
> time)  It could just be that I'm more dense than usual :-)
> 

'More dense than usual' it is:  I forgot to ratchet up the atom count
when I got profiling going.  *Then* the local/global conversions start
to dominate.  (The only reason I cranked them up that high originally
was to get some FPS distance between the Cog and Spur Squeak runs.  At
lower atom counts where drawing dominates, Cuis is still significantly
slower than Squeak running on Cog)

> I can definitely see how that could cause a problem doing 1000s of local
> to global conversions per frame...
> 
> > It is possible to optimize it back. It just requires some work.
> > 
> 
> Fair enough... but I still think that things are generally off
> performance-wise with Morphic... (it might just be that we've got a
> bunch of fairly unoptimized code similar to what's going on with
> BouncingAtomsMorph that will take some time to work through, but things
> are definitely feeling slow-ish from a UI standpoint)
> 
> > Cheers,
> > Juan Vuletich
> > 
> > >> Cheers,
> > >> Juan Vuletich
> > >>
> > >> On 8/12/2015 6:36 PM, Phil (list) wrote:
> > >>> I noticed a while back that something appeared to be going on with Cuis
> > >>> drawing performance (at idle on my system Morphic consumes ~20% of VM
> > >>> CPU *miniumum* according to ProcessBrowser) and this seems to give an
> > >>> indication of what it's currently costing in drawing performance...
> > >>>
> > >>> After seeing the Squeak 5.0 announcement, I was curious to see roughly
> > >>> how much of a speed boost we might be able to expect from Spur down the
> > >>> road.  So I decided to look at BouncingAtomsMorph to try to get a rough
> > >>> apples-to-apples comparison and was quite surprised: Spur was faster,
> > >>> but it was too much faster.  So I dropped back to Squeak 4.5 and it also
> > >>> performs much, much better than the Cuis version on the same VM.   Here
> > >>> are the numbers I'm seeing using BouncingAtomsMorph with roughly
> > >>> comparable (i.e. eyeballed) morph sizes and atom count set to 5000:
> > >>> Squeak 5.0 (Spur VM from all-in-one download): 29-31 fps
> > >>> Squeak 4.5 (Cog VM 15.25.3390): 24-26 fps
> > >>> Cuis 2440 (Cog VM 15.25.3390): 6-8 fps
> > >>>
> > >>> Granted BouncingAtomsMorph is not 100% identical from a source code
> > >>> standpoint but it's not nearly different enough where I'd expect that
> > >>> sort of difference.  Is this a platform-specific issue (I'm on Linux) or
> > >>> are others noticing drawing issues as well?
> > >>>
> > >
> > >
> > 
>