Real Software Forums

The forum for Real Studio and other Real Software products.
[ REAL Software Website | Board Index ]
It is currently Sun May 28, 2017 9:10 pm
xojo

All times are UTC - 5 hours




Post new topic Reply to topic  [ 17 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: Cocoa and performance
PostPosted: Mon Apr 08, 2013 12:37 am 
Offline

Joined: Thu Jan 05, 2006 1:44 am
Posts: 13
Location: Australia
Hi all,

I suppose I am looking for some re-assurance. I have been a Mac fan since I bought one of the first Classics in 1984. I am now retired and use my Mac for developing programs as a hobby.

One program I produced some time ago was a real-time animation of a midi-file. I used it to "learn" RealBasic and introduced quirks like "steam" from the pipe instruments (with a "smoke puffs" credit to Joe Strout who got me hooked with his excellent "Three Ways to Animate in REALbasic"). One early criterion I set myself was to use "basic" RB and I even managed to implement pitch bend with the NotePlayer. (No disrespect to midiMBSPlayer, which I also use.) In order to get the necessary performance out of my then PowerPC, I used graphics.window and graphics.canvas, etc but then I had to change it to use only paint events. That was when I invented the acronym "Rather Excessive And Laborious Booleans As Semaphores In Canvases :-). Again, to get the necessary performance - mainly so as not to miss the animation of ANY note-on and note-off events - I needed copious refreshrects of the smallest areas I could get away with, and resorted to using a microsecond-based loop for timing and therefore a thread to update the GUI. Obviously, I had to take care to ignore unsolicited and unexpected paint events! An interesting exercise, with 4 different types of musical instrument animation.

So now we have Cocoa on the horizon so I recently "bit the bullet", removed the threads and now use a timer for the wait between midi events. I am happy to say my concerns over the accuracy of the built-in timers were unfounded but of course I still need all the help the refreshrects, etc. give me. Imagine my satisfaction when it all worked within an hour or two and I am still in awe of the software development features of RS. BUT imagine my disappointment when I set Cocoa in the Build options and got appalling performance. Not only subjectively - with obvious audio glitches but also objectively - I have a custom control showing the current over-run in msecs. This is the time gap between where I am in the midi-file and the elapsed real-time. Under Carbon, the overrun in my test midi is negligible - but with Cocoa, it is regularly "in the red zone". I can switch animation off, and doing so enabled me to confirm that it is indeed the graphics that is solely to blame.

Incidentally, the performance hit was about the same as when I briefly toyed with Mountain Lion. Is there a connection?

Where do I go from here? I suppose I am fortunate and I have the option of staying with Snow Leopard and RS 2012 R2.1 - but am I the only one who finds all this very frustrating?

I hope someone can show me that I should hang on and that things will get better. I cannot afford to replace my Mac with the next most powerful offering - just to hide the growing OS overheads.

Help?

_________________
OSX v10.6.8
2.66 GHz Core2Duo 4GB


Top
 Profile  
 
 Post subject: Re: Cocoa and performance
PostPosted: Mon Apr 08, 2013 1:13 am 
Offline

Joined: Mon Aug 15, 2011 10:25 pm
Posts: 293
While you are not able to update the canvas (or any of the GUI) from a thread, is there any reason one could not draw a picture in the thread, save it to a property of the canvas and let the canvas use that picture from its paint event?

_________________
Real Studio 2012r1.1 | MacBook Pro i5, 10.6.8 | Windows 7


Top
 Profile  
 
 Post subject: Re: Cocoa and performance
PostPosted: Mon Apr 08, 2013 7:27 am 
Offline

Joined: Mon Aug 14, 2006 9:33 pm
Posts: 1774
At the risk of stating the painfully obvious, Real Studio's Cocoa ability is not yet ready for prime time. We can hope for improvement with the release of 2013r1 (soon, I hope). But the reality is that, with the modern Mac systems, you MAY have to go to CoreAudio, CoreGraphics, etc either through declares in RS or using XCode, to get the kind of performance you are looking for. Progress has its costs.

_________________
Roger Clary
Class One Software
Educational Software for Lifelong Learning
http://www.classonesoftware.com


Top
 Profile  
 
 Post subject: Re: Cocoa and performance
PostPosted: Tue Apr 09, 2013 1:22 pm 
Offline

Joined: Wed Feb 04, 2009 1:43 pm
Posts: 427
I have updated all my apps for Cocoa and they are equally fast drawing stuff compared to Carbon.

A good start:
change all .refresh to .invalidate


Top
 Profile  
 
 Post subject: Re: Cocoa and performance
PostPosted: Tue Apr 09, 2013 10:34 pm 
Offline
User avatar

Joined: Fri Sep 30, 2005 11:00 am
Posts: 583
Location: Beautiful Taiwan
I have to say that I've not seen any performance degradation with 2012r2.1.

However it's difficult to say exactly what is the cause of the slow down. One thing I've learnt is to draw at least as possible in each cycle. For instance if you are only updating a small section, then use either refreshrect or invalidateRect. Then in the paint event you now have the areas array which will hold which area needs updating.

For instance many of our apps, draw an image over a background. The background is a tiled pattern with a gradient overlaid. However when the user adjusts a slider, we only want the image to update, so we call invalidate and pass in the image rectangle.

In the paint event we check to see if there is a rectangle and it's dimensions. If there isn't a rectangle or the dimensions are significantly different than our image rect, we redraw the whole canvas otherwise we only redraw the edited image.

The difference between refresh and invalidate is dependent on your needs. Refresh asks the drawing to be done now, while invalidate will mark it as dirty and then the drawing will updated on the next loop. For instance, if you have a method that calls refresh multiple times, you're wasting CPU as the drawing will be updated multiple times before the loop is returned and displayed to the user.

I hope that this helps in some way.

_________________
Sam Rowlands
rMBP 15" @ 10.8 & '08 MBA 13" @ 10.6 + 10.7, RB2012
http://www.ohanaware.com/
AppWrapper - Prepare Apps for Mac App Store & OS X 10.8 - http://www.ohanaware.com/appwrapper/


Top
 Profile  
 
 Post subject: Re: Cocoa and performance
PostPosted: Wed Apr 10, 2013 12:51 am 
Offline

Joined: Mon May 30, 2011 12:56 am
Posts: 702
As an eye opener, add some debug logging code in the various paint events.

When I did this in the face of slow performance, I discovered that some paint events were almost constantly firing.
I found some of this was due to controls placed close together, causing 'cascade' refreshes.
By moving things around, using .invalidate instead of refresh, and on occasion invalidaterect

By getting it down to <one or more changes> = one only paint things work fine again.

Also look into erase background: is it needed? It seems to me that if you are painting the whole area, you dont need to erase the background first, so if that step is omitted it should run a cycle or two faster.


Top
 Profile  
 
 Post subject: Re: Cocoa and performance
PostPosted: Wed Apr 10, 2013 7:06 am 
Offline

Joined: Thu Jan 05, 2006 1:44 am
Posts: 13
Location: Australia
Hi shaosean,

Thank you for your reply.

Unfortunately, I still have to use a refresh or refreshrect somewhere, to "force" a paint event to maintain animation synch.

However, your suggestion made me analyse my application more closely and I realise that some of my code in the paint event would probably be better placed in the timer code. I would guess that someone would tell me that it is good practice anyway to minimise the activity in a paint event - see below.

Regards

Bill

_________________
OSX v10.6.8
2.66 GHz Core2Duo 4GB


Top
 Profile  
 
 Post subject: Re: Cocoa and performance
PostPosted: Wed Apr 10, 2013 7:07 am 
Offline

Joined: Thu Jan 05, 2006 1:44 am
Posts: 13
Location: Australia
Hi Roger,

Thank you for your reply.

I will delay any further comment on Cocoa until after the 2013 release, but it would be useful to know if the problem is with RS or with Cocoa - see below.

I have toyed with the idea of moving to XCode before, but after a long career in "Computer Systems", I managed somehow to avoid C and its variants. Thus, moving to C, XCode, etc is rather daunting at the moment. I am also pretty ignorant about the use of declares. Which bullet to bite is the current problem - but see below.

As for progress, I agree with you. But I believe that the cost to us mere mortals should and could be less. Some leadership on how to convert applications from SpriteSurface would not have gone amiss. The same for the removal of graphics.window and graphics.canvas and for updates of the GUI from a thread (despite examples showing exactly that solution). What will replace NotePlayer? When will NotePlayer be removed and what will replace it? I'm sure there are other example.

Meanwhile, despite this rant, my confidence in RS has been restored.

Regards

Bill

_________________
OSX v10.6.8
2.66 GHz Core2Duo 4GB


Top
 Profile  
 
 Post subject: Re: Cocoa and performance
PostPosted: Wed Apr 10, 2013 7:08 am 
Offline

Joined: Thu Jan 05, 2006 1:44 am
Posts: 13
Location: Australia
Hi atarikid

Thank you for your reply.

I previously tried changing .refreshrect to .invalidate but this had the effect of restoring past problems of event synch. But after your response, I tried again. This time (because I decided to be less concerned with my hardware performance), I reduced my "clever" minimisation of the draw area and I now basically re-draw the whole canvas instead of a just a bit of it. Obviously, my invalidates were changed to the version without parameters. I also found that with a careful use of some refreshes, I could get the effects I needed. And the Cocoa version is now running very well.

Thank you for nudging me.

Regards

Bill

_________________
OSX v10.6.8
2.66 GHz Core2Duo 4GB


Top
 Profile  
 
 Post subject: Re: Cocoa and performance
PostPosted: Wed Apr 10, 2013 7:08 am 
Offline

Joined: Thu Jan 05, 2006 1:44 am
Posts: 13
Location: Australia
Hi Sam

Thank you for your reply.

You will by now have seen earlier comments.

I have not taken advantage of the relatively new areas concept in the paint event but your explanation makes me want to investigate its use more fully. Your explanation of the differences between refresh and invalidate was enlightening. I was not aware that a refresh(rect) does not necessarily imply an "immediate" change to what is displayed.

Regards

Bill

_________________
OSX v10.6.8
2.66 GHz Core2Duo 4GB


Top
 Profile  
 
 Post subject: Re: Cocoa and performance
PostPosted: Wed Apr 10, 2013 7:09 am 
Offline

Joined: Thu Jan 05, 2006 1:44 am
Posts: 13
Location: Australia
Hi kermit,

Thank you for your reply.

I added some logging code to various paint events when I first embarked on the midi animation exercise. It was the (surprising) results of this that produced quite a lot of booleans to try to do the right thing in the paint event of for example arrays of (classes with) canvases.

I really wanted something like:
a) wait for the required midi period
b) program the audio (mainly note-on or note-off)
c) animate the note-on or note-off

Instead, I got:
a) as above
b) as above
c) request (by refreshrect) that at some future time the paint event for the relevant canvas AND others close by - AND the relevant window - would be activated.

Now I know the purists would say "Bill - you're old fashioned. You're thinking sequentially instead of thinking event-driven". But I would say that there are some applications which are sequential by definition. And midi file processing is a classic example.

Sorry to use a response to your very helpful reply to betray my sequential background - I hope you understand.

And I will certainly re-visit the the uncertainty principle of adjacent controls. But does anyone know how far away a control needs to be in order not to be involved?

And I will certainly investigate the default of erase background.

Regards

Bill

_________________
OSX v10.6.8
2.66 GHz Core2Duo 4GB


Top
 Profile  
 
 Post subject: Re: Cocoa and performance
PostPosted: Wed Apr 10, 2013 8:22 pm 
Offline

Joined: Thu Jan 05, 2006 1:44 am
Posts: 13
Location: Australia
Hi Sam

I'm still a bit confused about your last point. Are you saying that from the user's and screen's point of view, there is no difference between refresh and invalidate? I mean, what is the difference between them from the paint event's point of view? What mechanism does the drawing of a dirty bit of canvas if it is not a paint event? What is it that is accumulated until the "loop is returned"? Sorry about all the questions - it's just a sign of my ignorance and a wish to understand.

Regards

Bill

_________________
OSX v10.6.8
2.66 GHz Core2Duo 4GB


Top
 Profile  
 
 Post subject: Re: Cocoa and performance
PostPosted: Wed Apr 10, 2013 8:22 pm 
Offline

Joined: Thu Jan 05, 2006 1:44 am
Posts: 13
Location: Australia
Hi Sam

I'm still a bit confused about your last point. Are you saying that from the user's and screen's point of view, there is no difference between refresh and invalidate? I mean, what is the difference between them from the paint event's point of view? What mechanism does the drawing of a dirty bit of canvas if it is not a paint event? What is it that is accumulated until the "loop is returned"? Sorry about all the questions - it's just a sign of my ignorance and a wish to understand.

Regards

Bill

_________________
OSX v10.6.8
2.66 GHz Core2Duo 4GB


Top
 Profile  
 
 Post subject: Re: Cocoa and performance
PostPosted: Wed Apr 10, 2013 10:53 pm 
Offline
User avatar

Joined: Fri Sep 30, 2005 11:00 am
Posts: 583
Location: Beautiful Taiwan
by-gum wrote:
Hi Sam

I'm still a bit confused about your last point. Are you saying that from the user's and screen's point of view, there is no difference between refresh and invalidate? I mean, what is the difference between them from the paint event's point of view? What mechanism does the drawing of a dirty bit of canvas if it is not a paint event? What is it that is accumulated until the "loop is returned"? Sorry about all the questions - it's just a sign of my ignorance and a wish to understand.

Regards

Bill


No worries, I apologize if I wasn't clear (it's a bad habit of mine).

Okay, let me try it this way. In a method, if you call Refresh 5 times, the Paint event will be executed every time you call refresh. However the screen won't update until the method is completed and it returns to the loop.

However if you call invalidate, you can call it as many times as you like as the Paint event will only fire once the method has completed, and the paint event only fires once.

For most things, calling invalidate is the best way.

I hope that this makes a bit more sense.

_________________
Sam Rowlands
rMBP 15" @ 10.8 & '08 MBA 13" @ 10.6 + 10.7, RB2012
http://www.ohanaware.com/
AppWrapper - Prepare Apps for Mac App Store & OS X 10.8 - http://www.ohanaware.com/appwrapper/


Top
 Profile  
 
 Post subject: Re: Cocoa and performance
PostPosted: Wed Apr 10, 2013 11:14 pm 
Offline
User avatar

Joined: Fri Sep 30, 2005 11:00 am
Posts: 583
Location: Beautiful Taiwan
Oh forgot, it's my understanding that there is an 'event loop' which executes at certain intervals, in this the apps does a great deal of many things, including calling methods and events based upon the users actions and at the end of the loop it then updates the window or screen.

_________________
Sam Rowlands
rMBP 15" @ 10.8 & '08 MBA 13" @ 10.6 + 10.7, RB2012
http://www.ohanaware.com/
AppWrapper - Prepare Apps for Mac App Store & OS X 10.8 - http://www.ohanaware.com/appwrapper/


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 17 posts ]  Go to page 1, 2  Next

All times are UTC - 5 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group