Priest of the Order of the Butterfly
Posts: 601 from 2007/7/29
Quote:
jPV wrote:
The core Hollywood interpreter is a bit over 2MB in size and it's included in the compiled executables, so you can't avoid that. The actual code doesn't make it that much bigger, but if you embed some resources into the executable (like images, audio, plugins, other external stuff) then it grows just like executables on any other language too. I don't think the 2MB is that big issue with nowadays mass storage and memory sizes.
This is what I’m saying. You always have big programs because of they are made with Hollywood, even if they have very tiny functionality. Yes, most disks are large enough today. But is this a reason to waste the space? This is the Windows response: “we have enough of disk and RAM, and if not then you have to buy more”. Amiga/MorphOS was always tiny and fast, also because of its small size. A 2MB file loads longer than a 200kb file. And look at similar software on MorphOS. For example look how small JukeBox is. Or compare Vpdf with RNOPDF. Vpdf is smaller and faster.
Quote:
What do you mean by "hws"? .hws is a script code file which is embedded in an executable and not visible for users. Or do you mean .hwp plugin files? The plugin files are like libraries and you don't have to keep them in the program directory, you can move them to Libs:Hollywood/ if you want. I just like to bundle them with my programs so that users don't need to do anything to launch the programs, because as said, I think HD space isn't an issue nowadays.
Yes, I meant hwp, not hws. I place mine in the LIBS: dir.
Quote:
But how that 2+ megabytes executable size affects to the speed? At least on our PPC platforms Hollywood programs start immediately unless you have veeery slow and fragmented HD? When I talked about skills of a programmer I meant generic speed when using the programs, not about something that would be affected by an executable size.
I don't know how it affects the speed. I just see THAT it does. My disk does not look very fragmented in the defrag tool. And other programs load much faster because they are much smaller. But I also don't know how it would be with a 3MB program that is not written in Hollywood.
Quote:
Hmmm.. window moving is done by OS (Intuition) and nothing in Hollywood should affect to that. And MUI GUI is handled by MUI of course... I don't understand why there would be difference in speed, unless programmer himself decided to do something when there will be a notification about resizing or switching tabs... can you give a more exact example which Hollywood program has a slower window handling? Only thing that I could think it that if a MUI window has a Hollywood display embedded in it and it scales with resizing realtime.. graphical scaling is CPU heavy process, RNOEffects is probably slow becasue of this. But if it only has standard MUI objects on it, I don't understand why it would be slower... does it make full CPU load or something like that or is it just refreshing slower?
I don’t know how they do it, too. Or if it depends on the programmer or Hollywood. I would think Hollywood because I just observe it with every Hollywood MUI program that I try. This is why I usually not try or use them: because they act so slow. Just when I remove the size a bit or move the windows around the CPU meter already goes up and the windows and redraw start to lag. But not with non-Hollywood programs. Slow are for example RNOPDF or RNOEffects or also Sqlman. Or Mediathek: http://evil.bplaced.net/index.php?name=Mediathek&page=AboutIf there is anything I could look for then please tell me.
Quote:That's not entirely true. While all the latest features might not be supported yet, you still can use MUI4+ features. There's the
mui.IsVersion4 function too, which I have been using in my programs to change the GUI features depending on the platform.
Ah, I didn’t know that. And I didn’t read which other Hollywood programs use it. Hopefully Hollywood will support MUI5 one day.
Quote:
It doesn't crash, but exits cleanly without taking the whole OS with it. I think it's the best feature in Hollywood, because if there's a fatal bug in the code, it informs about it and quits nicely. You can then make a bug report to the developer then and it even tells the line where the error occured, what could be better! When you make a similar bug in C, it very likely trashes memory and breaks something that you don't see immediately, or crashes other software or the whole OS immediately. Hollywood programs are very safe to run in that regard! This is especially useful on our systems that don't have memory protection, and I rather choose stability than forcing a program to run in a broken state.
Okay, it does not crash the OS, that’s true. But when something went wrong and it is unsafed, then you immediately lose it, for example searches in the Mediathek program. Then you cannot even copy and paste the text which would still work in some other programs. The exit of those programs reminds me of Amiga Basic or Rexx programs.
Quote:
But that said, a programmer can also disable the internal error handler in Hollywood if wanted (permanently or temporarily) and let the mess escalate, or write your own error handling function. For example, I have made my own error handling function in RNOPublisher, and if a fatal error occurs, it doesn't quit immediately but writes a backup file of the current project before exiting, and informs a user about it.
And is that more stable or faster or user-friendly? At least it sounds better. I do not use the publisher much because my main feature would be to import and edit an existing PDF file. These it cannot load.
