Mailing Lists: Apple Mailing Lists

Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dock icon vs multi-processed application



This might not work for your application, but one approach I'd go with if I had
that many UI elements is to consider doing my own drawing and tracking of them
when they're visible or clicked on rather than creating a separate element for
each one. If you know how to best manage 2000-3000 objects on a window in your
own application, your code could easily be faster than anything a UI framework
developer (e.g., Qt, Apple, etc.) could provide, since they're more concerned
about a general-purpose solution. And, organizing these objects in a
procedural manner, rather than using object-oriented methodologies for each one
might speed things up.


An example that comes to mind would be a Sim-Universe-like application, in which
you might initially have developed each galaxy in your universe to be an HIView
and each solar system/star/planet/moon/asteriod/etc. to be a
successively-enclosed subview. Yes, that probably would be esoterically
designed, but it might be better implemented via some hash methodology based on
coordinates.


And, it might work great to do the rendering in each thread/task and mark them
as being renderable to the main thread (perhaps using a bitmask flag or a
CarbonEvent) where it would then be responsible for pushing that rendering to
the real window buffer/screen.


Anyway, that's some food for thought that I hope might help you in some way.

Quoting Jeremy Friesner <email@hidden>:

On Monday 22 October 2007 12:47, Eric Schlegel wrote:
Maybe you should use fewer widgets? Neither HIToolbox nor AppKit are
really tuned to handle that many views very well. Qt might not be
either.

Yup... there is always the option of making my own "uber widgets" wherein I
have my own internal "widget tree" and do all the appropriate event handling
logic, etc myself.


OTOH, that seems like a huge amount of redundant code, and even if I
implemented it all there's no guarantee that my GUI implementation would be
much faster than TrollTech's or Apple's version (after all, their engineers
are much smarter than me ;^))

Add to that the fact that TrollTech seems like they are already headed in that
direction for their library (the still-in-development Qt 4.4.x has been
redesigned to present just a single window-sized uber-widget to the OS, with
Qt handling the widget hierarchy in an opaque manner... although it sounds
like they may not implement that mode under MacOS/X, alas)... and it seems
even more like "rolling my own" would be a waste of time in the long run.


And even if there is a way to optimize my GUI code to be "fast enough" to run
in a single thread, there will always be another app (or a later version of
my app) that will want to do more in the GUI... and as we go from dual core
to quad core to 16 core, the potential speedup to be had by allowing multiple
GUI threads will only get larger.


So while there are doubtless other ways to solve this particular problem, it
would still be cool to have a multi-process GUI solution too.


IMHO :^)

-Jeremy
_______________________________________________
Do not post admin requests to the list. They will be ignored. Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden


This email sent to email@hidden




_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden

This email sent to email@hidden
References: 
 >Re: Dock icon vs multi-processed application (From: Scott Ribe <email@hidden>)
 >Re: Dock icon vs multi-processed application (From: Jeremy Friesner <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.