Cocoa Build Graphics very slow

Hi all,
I have a project with a unique window concept. To realize this, my window is split into two half sides with a page panel on every side. On the right side there is a second page panel on the main page panel. I used a lot of canvases to create my own interface like custom list boxes, search fields an so on.

When I compile the project with carbon the interface in the final app is very fast and I can’t see any graphical glitches. Now with cocoa out of beta I tried to compile it with cocoa, but the interface in the final app is sluggish slow. When I change the second right page panel, there is a second or two where nothing happens visually, then the list of the next page appears, but in the canvas area above the list (custom search field) the graphics of the previous page still shows through and after another second the custom canvas is filled up. Maybe it’s not really a second but very visible. In carbon after the click on the button who switches the page panel the page is instantly and completely shown, no wait time no visual glitch!
Should cocoa not be the modern and fast framework? or is it simply badly implemented into Xojo ? or do I oversee something ?

Best regards,

How and where are you doing your drawing? Are you using refresh or invalidate? Do you do your painting in the paint event?

And no I’m not seeing any slowdown in Cocoa. My application has a complicated 3 pane interface with several containers and some canvases.



Try consolidating canvases. In general, drawing multiple pictures into a single canvas is preferable to using multiple canvases.

Do you use the built in Focus RIngs? I have a Canvas based Listbox that slowed way down in Cocoa until someone on here mentioned turning the Focus Ring off and the speed went back to normal.

I do all drawings in the paint event of canvases or in the Cell Paint Event of lists. All customized controls used are classes. I attach a screenshot to show the interface. The search zone with calendar buttons and so on is one canvas (it also draws and resizes the list headers), the tabs on top, the buttons at the bottom and the side lines are another canvas and the list is a custom listbox. The left one just uses a special format to display the lines, the right one groups rows as blocks depending on the sort criteria (here records are grouped visually by date).
Sorry for blurring out confidential data.

What I do not understand is that when I compile it with carbon it’s fast as hell, but with cocoa it sucks really.

I suggest you are doing something horribly wrong… as I have an extremely complex app that is my first 100% Cocoa app, and I am getting screen refresh times in the .004 second range. And this is drawing hundreds of shapes, a background grid, AND dragging shapes around the screen (all in realtime) with no flickering, flashing or delays.

Granted this code worked crappy under Cocoa until XOJO came out… and worked great in Carbon… but now it works fantastically under Carbon.

I use ONE Canvas… and one PICTURE to provide a screen buffer for when I’m dragging items around…

That all being said… your display looks like a few Listboxs with custom cellpaint events might have been a better choice… but that is just a guess on my part based soley on what I see

Any sort of example project would help a lot. Failing that, a sample from Activity Monitor (or the command line ‘sample’ utility) could prove helpful.

Also, how many controls are we talking? From the looks of it, only ~30?

@Dave S [i]

I don’t think so. As it is fast as hell under carbon, there can not be a big mistake. The only mistake can be in the way the Xojo framework handles this. A good transitional framework should make transition invisible.
By the way I see other changes that make the transition from carbon to cocoa a pain for large projects. I had a movable modal dialogue that worked fine under carbon, but in cocoa, as soon as I type the first letter in a textfield, menu enabling takes place and in the menu enabling I refer to another window, so the window looses focus and the next letters typed go to nowhere, so that I have to click again in the window to get focus back. Maybe (or not) this is as things should be, and I worked around by checking if my modal dialogue is still open in the menu enabling, but as sad the framework should handle this.
I wrote text files under carbon and our accounting program was able to import them. They had the extension .txt . Now under cocoa the extension is .asc and even changing it to text ends up with a ‘file format not compatible’ in our accounting software. I still have to look how to handle this, but these are things that should not happen.

@Joe Ranieri
We have a page panel with 6 pages over the entire window, on this page panel we have on every page one page panel on the right side. These pages contain textfields, labels or canvases or list boxes. Visible at one time are just some controls. As already explained, the white tabs, side lines and white buttons are all handled by one canvas. On this canvas is just a custom list. The entire gray array above the white buttons (search field, date selectors, listbox headers are all drawn inside one canvas). Everything is drawn very fast, but what happens is that that there is a long delay where the the canvas with the search field is transparent and the previous page displayed shows up, after a second or so the content is drawn very fast. The problem is the delay, not the pure drawing time.

Cocoa is very different from Carbon. Expecting to have everything working the same when moving from Carbon to Cocoa is pretty unrealistic. Drawing is different, events may have a different order. Extensions do not change, by the way.

Yes they do. Standard text extensions are .asc; …;.txt
Carbon automatically selects the last extension while cocoa selects the first one. That’s a good example of what I want to say. It’s not cocoa who selects the first one, but the Xojo framework who passes the first one instead of the last one. This unnecessary change breaks compatibility.

Without an example project or the output from Activity Monitor (or the command line ‘sample’ tool), I can only speculate.

Are you using focusRings? feedback://showreport?report_id=26903