various skins - should we compile them all or "call" them?

[kortezzzz]

I would like to use 4 different skins with matching 4 different set of knobs, buttons, etc. I have 2 options:
1) Compiling them all to 1 big file and control the skinning with radio buttons
2) Storing the whole bunch of png. files in the plug-in's "system folder" and calling them in real-time straight from there, any time the skin would be switched.

I know that plugins coded in native language like C++ use the second approach, but I'm not sure if it would be a good idea to do that with FS, since it doesn't use the same graphics method. So, which is faster\"cheaper"?

[tulamide]

1) Faster
2) Cheaper

Loading from disk is always slower than transferring bits in memory. If your resulting png is small enough (always calculate width * height * 4 = bytes) to be kept in memory all the time, prefer the first solution. It will only access the disk once (when loading the plugin).

If the individual files are small enough and the loading only takes place when switching the skin, it might be preferable to load them from disk to keep a smaller memory footprint.

[kortezzzz]

Thanks tulamide. My skins are h-u-g-e, so the second solution has no chance
Anyway, following your comment, I gonna give a try to the second method in some of my smaller designs, although I'm kinda in doubt to see any benefits from this method with FS platform.

[RJHollins]

I wish is was possible to do more/better graphics details within FS

Particularly items like main faceplate panels ... metal/aluminum that looked convincing.

It seems the choices of patterns available in RUBY don't provide things like blurring or diffusion ...

If we could, it would save a lot of RAM not having to load/store PNG files created with 3rd party graphics apps.

[kortezzzz]

@RJHollins

Even if your fantasy come true, I'm not sure you would save that much amount of RAM because complex graphics have
stiff requirements in any platform. So what else can be done? Well, I regularly use image compression for knobs and other elements by using this site

http://compresspng.com/

The compression is really crazy feature. Sometimes you end up with 90% smaller file than the original image without loosing significant quality!
I never use it for the major background image to keep it as sharp as possible, but its ok for knobs, buttons and other elements since you might end up with 60% smaller file after exporting and keep your plugin's performance at it's best

[tulamide]

That's true only as long as you realize that it's only a smaller footprint on disk. No matter how much you compress your files, when they finally end in memory they consume 1 byte per channel per pixel. Flowstone uses 4 channels, ARGB, so it's 4 bytes per pixel

Furthermore any compressed file (png is a format that allows for lossless compression) needs to be expanded prior to usage, so it's an additional processing step that you don't have with uncompressed files. It is not that much for a single file, but for hundreds of them it will be noticable.

Since compression is a defined standard for png, you can also compress from within any image editor that supports export to png. You save the most if you omit the alpha channel on images that don't have any transparency.

It may be that the website you linked to does more than just the defined compression to achieve high compression rates. In that case it is very likely that they use lossy algorithms (png is already pretty good at lossless compression).

Regarding more options: As soon as FS supports OpenGL, all tasks like blur, diffuse, light shading, shadows, etc. can be transferred to pixel shaders. Those are algorithms that will be executed on one of the cuda cores (NVIDIA)/ stream cores (ATI). Which means not only way faster processing, so that realtime effects are no problem, but also parallel processing (FS can calculate the audio streams, while the graphic card calculates the next frame) - and that reduces the cpu load by at least 50%.

[kortezzzz]

Thanks for the detailed info tulamide, once again.

No matter how much you compress your files, when they finally end in memory they consume 1 byte per channel per pixel. Flowstone uses 4 channels, ARGB, so it's 4 bytes per pixel

That's very interesting point then. If I understand clearly, are you actually saying that 3th party compression is almost useless since the memory usage is effected only by the number of pixels? AFAIK, compression doesn't change that factor (or the image would warp)... so there are no significant benefits from compression other than shrinking the exported file?

Furthermore any compressed file (png is a format that allows for lossless compression) needs to be expanded prior to usage, so it's an additional processing step that you don't have with uncompressed files

I don't really understand what is a "lossless compression" or "lossy algorithm" and what its actually "expending prior to usage".

You save the most if you omit the alpha channel on images that don't have any transparency.

Kinda lost you here... what's the point in adding a knob without any transparency?

[tulamide]

so there are no significant benefits from compression other than shrinking the exported file?

Exactly. Compression is always a process to minimize the access of the slowest device, which is the harddisc or the internet. For large files it is faster to load a compressed file and then expand it in RAM, than loading that file uncompressed from the device.

I don't really understand what is a "lossless compression" or "lossy algorithm" and what its actually "expending prior to usage".

Compression means to summarize parts of the file, so that it gets smaller. A lossless algorithm (an example here is png) takes care that no info from the original gets lost due to compression. A lossy algorithm (an example is jpg here) is more interested in getting the highest savings on file size and therefore allows losing informations from the file. For example, if two different colors are next to each other so that the user won't be able to differentiate between them they are simply converted to the same color. You can see the effect on highly compressed jpgs when you zoom in a little. You will notice a kind of a grid, reminding a bit on a chess board.

Here's the very basics of a lossless compression:

Code: Select all

Let's say the original data contains this:
2222222222222222333333333333333333333333
Instead of writing that into a file, you could instead write instructions:
16
2
24
3

Now, instead of 48 bytes, you only write 4 bytes (that's a compression rate of over 90%!)
The application that deals with this compressed file only needs to know, how the file is
compressed. In this case it simply writes the number of occurences (here 16 and 24)
followed by the data (here 2 and 3). The app then writes 16 times the value 2 into memory
and 24 times the value 3. This process is the expansion. After that process the data in
memory looks exactly as the original before it was compressed:
2222222222222222333333333333333333333333

And here are the very basic differences to a lossy algorithm:

Code: Select all

Lets just take the value 2 this time, but insert just one different value:
2222222232222222
Our lossless compression algorithm would generate this:
8
2
1
3
7
2

That's 6 bytes instead of 16. Still ok, but only 63% this time. A lossy algorithm would instead argue that the value 3 only appears once inside a large block of the same values and would therefore be neglectible. It would decide to replace that value 3 by the value 2 to be able to write:
16
2

It reached a compression rate of 16:2 or 88%, and will be proud to have beaten the lossless algorithm. But when expanding the compressed data in memory, they both will look different:
2222222232222222
2222222222222222


For the best quality you should prefer a lossless compression. However, for audio data (which has a more chaotic series of numbers) it is very difficult to develop a lossless algorithm (mp4, mp3, ogg, etc. are all lossy algorithms), so there are only very few of them out there. I could only name one right now from my head, which is flac.

Kinda lost you here... what's the point in adding a knob without any transparency?

There isn't any. But GUIs don't just consist of knobs!. A rectangular button, for example, could be saved without the alpha channel. Or the background. And so on.

[kortezzzz]

Great explanation, man. I became smarter today. Thanks

[RJHollins]

same here ...

Thanks Tulamide