slow creation of sub-presenters

hello!

I'm developing an easy board game in Dolphin.and have problem with GUI.
I decided to represent a board as a bunch of sub-presenters gathered in
one Composite-Presenter (eachsub-presenter represents one "square" of
board).
Everything works fine but creating these objects is really, really slow.
It takes a few seconds
to create 100 sub-presenters and I can't even imagine how long would it
take to create 1000 of ones.
The only solution I can think of right now is to replace those
sub-presenters with only one and drawing all squares in one view. But
that seems to be
not quite object oriented (I would have to examine coordinates of mouse
event to detect which square was clicked).
Is there any other solution? What is the cause of such slow creating of
sub-presenters?

Thanks for any advice. BTW I'm using Dolphin 2.1

Michal

Michal,

> Everything works fine but creating these objects is really, really slow.
> It takes a few seconds
> to create 100 sub-presenters and I can't even imagine how long would it
> take to create 1000 of ones.

It would take a quite a while, though >1000 widgets is somewhat unusual.
It's quite easy to exceed 100 though, and that gets us to the answer that
you're not going to like:


> The only solution I can think of right now is to replace those
> sub-presenters with only one and drawing all squares in one view. But
> that seems to be
> not quite object oriented (I would have to examine coordinates of mouse
> event to detect which square was clicked).

That's exactly what you should do (IMHO at least).  Native widgets are known
to be inefficient when created in large numbers.  If you emulate, I predict
that you'll be amazed how easy it is to get dramatically better performance
than you saw with native widgets.  Native widgets are designed to be drawn
individually; even sloppy Smalltalk code that "understands" that you are are
drawing a few hundred boxes can cut down a LOT on GDI calls required to
render them.  You also get to skip the message queue bashing (hundreds of
times over) that Windows uses to do just about anything to the native
widgets.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Michal,

> I'm developing an easy board game in Dolphin.and have problem with GUI.
> I decided to represent a board as a bunch of sub-presenters gathered in
> one Composite-Presenter (eachsub-presenter represents one "square" of
> board).
> Everything works fine but creating these objects is really, really slow.
> It takes a few seconds
> to create 100 sub-presenters and I can't even imagine how long would it
> take to create 1000 of ones.

It's a good question but your experience is not particularly surprising. I
must admit that "a few seconds" for 100 windows does sound a bit slow but
that will depend on the speed of your machine. What you have to remember is
that each view attached to a sub-presenter is itself a Windows window (if
you see what I mean). The creation of each window involves many WM_ messages
flying backwards and forwards between Dolphin and the underlying operating
system. Some of the speed loss will be in the interface that Dolphin has
with Windows (which BTW we believe to very efficient) and the rest will be
in Windows itself. As a matter of interest you should find that ther former
is faster in newer versions of Dolphin than 2.1 but not by an order of
magnitude. Why not try a trial of Dolphin 4.0; you'll find it a *lot* better
than 2.1 in so many areas.

http://www.object-arts.com/Trial

You can even get a free copy of Dolphin 4.0 Value Edition with Ted Bracht's
book, The Dolphin Smalltalk Companion:

http://www.object-arts.com/wiki/html/Dolphin/DolphinSmallltalkCompanion.htm

> The only solution I can think of right now is to replace those
> sub-presenters with only one and drawing all squares in one view. But
> that seems to be
> not quite object oriented (I would have to examine coordinates of mouse
> event to detect which square was clicked).
> Is there any other solution? What is the cause of such slow creating of
> sub-presenters?

I don't think it's any less OO; you can still create separate objects for
handling each square (drawing and hit testing etc) it's just that you need
to make the overall board view redirect the messages appropriately. e.g.

Board>>onLeftButtonPressed: aMouseEvent
    (self squares detect: [:each | each containsEvent: aMouseEvent] ifNone:
[^self])
        onLectButtonPressed: aMouseEvent

Bear in mind that it's really a limitation of Windows not of Smalltalk or
Dolphin. You just need to adjust your OO strategy based on efficiency
concerns but everyone has to do this at one time or another.

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com
---
Are you trying too hard?
http://www.object-arts.com/Relax.htm
---

Andy Bower wrote:
> > It takes a few seconds
> > to create 100 sub-presenters and I can't even imagine how long would it
> > take to create 1000 of ones.
>
> It's a good question but your experience is not particularly surprising. I
> must admit that "a few seconds" for 100 windows does sound a bit slow but
> that will depend on the speed of your machine.

I managed to get a significant improve of speed by NOT using resources.
I just connect the proper aView Object(addSubView method) (I was
using createIn: before). Right nowcreating of 100 widgets is
unnoticeable and that's what I wanted.
Could anyone explain why difference is so big?

michal

Michal

You wrote in message news:[hidden email]...
> Andy Bower wrote:
> > > It takes a few seconds
> > > to create 100 sub-presenters and I can't even imagine how long would
it
> > > take to create 1000 of ones.
> >
> > It's a good question but your experience is not particularly surprising.
I
> > must admit that "a few seconds" for 100 windows does sound a bit slow
but
> > that will depend on the speed of your machine.
>
> I managed to get a significant improve of speed by NOT using resources.
> I just connect the proper aView Object(addSubView method) (I was
> using createIn: before). Right nowcreating of 100 widgets is
> unnoticeable and that's what I wanted.
> Could anyone explain why difference is so big?

Resources are stored in a binary filed form using the STB binary filer. For
simple controls especially, the STB overhead will dominate in relation to
the time taken to create the windows control. For more complex controls, or
those where a lot of Windows messages are sent to initialize them, it will
be less significant. STB has been significantly speeded up in later (than
2.1) versions of Dolphin, but even so if one repeats the de-serialization of
the same information 100 times then clearly there is an opportunity for
optimisation :-).

Regards

Blair

Michal,

I made MineSweeperShell a year ago with the same approach that you
have tried in your board app. The MineSweeperShell has 2D-Arrays of
Subpresenters dynamically created as the player choose the board size.
It took a lot of time as you say so when creating.

I could improve the speed quite a bit by using Symbols as the sub view
name when creating rather than using Strings. I guess the
CompositePresenter's itentity test over its many many subpresenters is
one big factor of the slowing down the creation speed.

Example:

  'cell-100-120' --> #cell-100-200
  'cell-i-j' --> #cell-i-j

Have a good one