Hollywood forums

Note: This is an archived post that was originally sent to the Hollywood mailing list on Fri, 30 May 2008 23:48:29 +0200

I've now had some time to play with it... looks very impressing indeed. Scrolling the list view is damn slow here on my Pegasos 2 with G4 1 Ghz CPU but I think there's a lot of room for code speedups once the basics are up & running.

I'm working on the feature to @INCLUDE applets but this can take some time because it involves several issues that require some thinking like dynamic code relocation and applets could also contain Hollywood objects like brushes, sounds, etc. Not quite easy to implement but definitely a must-have feature so I'll try to get that done for the next update.

The background redraw feature will also come so you can spare the SaveSnapshot() detour.

I think I'll also implement support for applet compression because currently, compiling scuilib.hws results in a whopping 350kb applet but there's a lot of 0s because of unused VM address space. With applet compression this should be reducible to 25% of the size because the VM bytecode is really pretty lengthy in memory but fast in execution.

You should probably also put some fonts into the package. I had to modify the script files because MorphOS does not have helvetica.font and diamond.font.

Note: This is an archived post that was originally sent to the Hollywood mailing list on Sat, 31 May 2008 08:04:42 -0000

I've now had some time to play with it... looks very impressing indeed. Scrolling the list view is damn slow here on my Pegasos 2 with G4 1 Ghz CPU but I think there's a lot of room for code speedups once the basics are up &

running.

Yes, the code need optimization, I've started with StringBox because in the next release they will be event driven, and when the the user will edit a string the remaining interface's objects will not be locked anymore. I will look at the ListView scroller routine to optimize it.

I'm working on the feature to @INCLUDE applets but this can take some time because it involves several issues that require some thinking like dynamic code relocation and applets could also contain Hollywood objects like brushes, sounds, etc. Not quite easy to implement but definitely a must-have feature so I'll try to get that done for the next update.

Great!

The background redraw feature will also come so you can spare the SaveSnapshot() detour.

This feature will speed up window's dragging and window opening, more I can use Double Buffer for single object rendering. Thanks

I think I'll also implement support for applet compression because currently, compiling scuilib.hws results in a whopping 350kb applet but there's a lot of 0s because of unused VM address space. With applet compression this should be reducible to 25% of the size because the VM bytecode is really pretty lengthy in memory but fast in execution.

You should probably also put some fonts into the package. I had to modify the script files because MorphOS does not have helvetica.font and diamond.font.

This was a mistake, in my mind there was the idea to put the fonts in the package...

Thank you for your time Regards Fabio

Note: This is an archived post that was originally sent to the Hollywood mailing list on Sat, 31 May 2008 12:12:06 +0200

This feature will speed up window's dragging and window opening, more I can use Double Buffer for single object rendering. Thanks

Be careful with double buffers. Remember that when you Flip() a double buffer into view, Hollywood will redraw the whole (!) display. This is comparably slow. If you only need to update a small region of your display, you should never use double buffers but simply create an offscreen brush, draw the refreshed stuff to it, and then display this offscreen brush. Double buffers are pretty slow in this case.

It seems that you use double buffers quite a lot. When you use a double buffer, you should always make sure that it's not slower than using an offscreen brush. For example, if your display is of the size 800*600 pixels and you now have to update a region of let's say 100*100 pixels, then it would be faster to do it without double buffering because Flip() would draw the whole 800*600 pixels, but this involves a lot of redundancy because you only need to update a small part of the 800*600 pixels, viz. 100 * 100 pixels.

Maybe in a future version, Hollywood will be intelligent enough to update only the necessary parts in double buffer mode. But currently, a call to Flip() will always refresh the whole display. So you shouldn't use double buffers when you only need to refresh a part of the display.

Note: This is an archived post that was originally sent to the Hollywood mailing list on Sat, 31 May 2008 18:07:24 -0000

Thank you for the hints, I will optimize the code following your directions. I've used DB because is the faster way (in code writing ^^) btw it's not the best way. For sure I will use the offscreen brush trick to update gadgets, these way I'll reserve a brush id that I will use for this purpose.

When I started this project I've thought about building a gadget drawing it into several brushes, one for each gadget status, maybe this is the faster way, but this approch is too much expensive in terms of memory usage.

The story is always the same: fast code = much memory, less memory = slow code But this is the funny part of programming!

Thanks again for helping

Regards, Fabio

Note: This is an archived post that was originally sent to the Hollywood mailing list on Sun, 01 Jun 2008 11:52:36 +0200

Thank you for the hints, I will optimize the code following your directions. I've used DB because is the faster way (in code writing ^^) btw it's not the best way. For sure I will use the offscreen brush trick to update gadgets, these way I'll reserve a brush id that I will use for this purpose.

When I started this project I've thought about building a gadget drawing it into several brushes, one for each gadget status, maybe this is the faster way, but this approch is too much expensive in terms of memory usage.

Yes, that probably consumes too much memory. But gadgets are mostly not very large in size so you can really draw them pretty fast. You just have to make sure that you do not draw anything more than necessary. The goal must always be to draw as little as possible. Using DisplayBrushPart() it is possible to draw only a part of a brush.

On another note, I noticed that your button implementation does not behave like a standard button in the following case:

1) press a button but do not release the left mouse button --> button gets selected: ok
2) now move the mouse out of the button's area while left mouse button is still
down --> button gets deselected: ok
3) now move the mouse into the button's area again (left mouse button is still
down) --> button goes into hover mode: wrong! --> it must go into selected mode
4) release the left mouse button over the button's area --> no event is triggered: wrong!
--> event must be triggered now

Well, this might be something for fine-tuning but normal buttons behave in the way that you can leave their area and enter it again and then the event still gets triggered. The GUIs of every OS I've seen do it that way. You can easily check it under AmigaOS because gadtools, MUI and Reaction also behave in this way.

Note: This is an archived post that was originally sent to the Hollywood mailing list on Sun, 01 Jun 2008 10:18:32 -0000

Yes, that probably consumes too much memory. But gadgets are mostly not very large in size so you can really draw them pretty fast. You just have to make sure that you do not draw anything more than necessary. The goal must always be to draw as little as possible. Using DisplayBrushPart() it is possible to draw only a part of a brush.

On another note, I noticed that your button implementation does not behave like a standard button in the following case:

True, I've to modifiy few things to implement this behaviour, in the next version every gadgets will react as expected, thank you for have you focused me on this problem ^^

Regards, Fabio

Note: This is an archived post that was originally sent to the Hollywood mailing list on Sun, 1 Jun 2008 10:03:45 -0700 (PDT)

In case anyone is unsure about how to implement what Andreas is describing here, the easiest way is to use the "MouseDown" message that buttons send to their functions. Whatever code is used under *Case "OnMouseDown":* should also be used under *Case "OnMouseOver":* inside of a *Switch msg.MouseDown*. Here is some sample code: