Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#119 closed enhancement (fixed)

Pen usage

Reported by: Mikhail Malyshev Owned by: Thore Böckelmann
Priority: undecided Milestone: 3.9-2015R1
Component: Bitmap.mui Version: 3.9-nightly build
Severity: minor Keywords:
Cc: OS Platform: AmigaOS3
Blocked By: Blocking:
Release Notes:

Bitmaps smaller than 30x30 pixels and with a definite palette (i.e. icons of .mcp classes) are now converted to ARGB data on truecolor screens to allow a penless display.

Description

On hi-colour screens MUI seems to be hungry for free pens it can/needs to use.
It is understandable for user defined pens (like Busy and Lamp)
but it seems that the images in the prefs take up colour as well.
They should do direct rendering to hi-colour screens (like backgounds do) and not consume valuable pens.
eg. I loose 120 pens on opening the MUI prefs, this is not good.

Attachments (1)

USED-PENS.PNG (126.2 KB) - added by Mikhail Malyshev 5 years ago.
pens used by images

Download all attachments as: .zip

Change History (21)

comment:1 Changed 5 years ago by Thore Böckelmann

On 16+ bit screen modes MUI will try to use as little pens as possible. Most pens are used by colormapped images and there is nothing MUI could do against this, because this is done by the datatypes system. And this is nothing that has changed recently. If you want less pens to be used then use a different set of images or "reuse" a fixed set of colors where ever it is possible.

Finally there is no point in keeping as much free pens as possible. Pens are there to be used. Otherwise you could render everything with just 2 colors. That would be enough as well for the basics. Why would you want to keep 200 pens unused?

comment:2 Changed 5 years ago by Mikhail Malyshev

Problem 1 - the pens seem to be used by the mcc classes images (icons in main list) last years they have been upgraded to nice coloured pics.

Problem 2 - I don't use anything but MWB default images, so only 8 already available pens are used/reused for main GUI. Background patterns don't use pens?
Even if they do, that's an extra 20 here.

Problem 3 - free pens are useful for many things, icons use pens, programs that run on WB use pens. (DOPUS, MusicPlayer Scopes, IconEdit ets.) So you can never have enough when you run some of these at the same time. And it's best not to waist any when it's not required.

A good example of not enough pens is busy mcc, if it is configured differently for different apps, you run out of colour very quickly.

comment:3 in reply to:  2 Changed 5 years ago by Thore Böckelmann

Replying to Michael:

Problem 1 - the pens seem to be used by the mcc classes images (icons in main list) last years they have been upgraded to nice coloured pics.

On truecolor screens the prefs page images will not use *any* pen, because they will be drawn as truecolor images. On colormapped screens these images will be reduced to a fixed palette of 216 colors. But since you were talking about truecolor screens this cannot be the cause.

Problem 2 - I don't use anything but MWB default images, so only 8 already available pens are used/reused for main GUI. Background patterns don't use pens?
Even if they do, that's an extra 20 here.

Wrong. The grid patterns (located between gradients and bitmap image in the image selection window) are mixed from the normal MUI pens. Hence they take no additional pens. How did you count the number of 20 pens?

However, bitmaps can take an arbitrary number of pens. It is your own decision which image you are using. The pen allocation and the remapping is done by the datatypes system. Again, matching colors will take no additional pens but will reuse the already existing ones. For different colors than additional pens will be used. MUI uses exact pen matching since ages, because one expects to end up with exactly the same bitmap background image as configured. And again, it is your decision if you use plain colors for a background or a fancy truecolor image which might get remapped and dithered for the application's screen and hence might require lots of free pens.

A good example of not enough pens is busy mcc, if it is configured differently for different apps, you run out of colour very quickly.

Honestly, if one manages to configure Busy.mcc in such a way that each application uses a different color set, eventually runs out of free pens and ends up with slightly wrong colors then this is not my problem. MUI 3.9 is not released with a reimplemented Busy class like MUI4. It is still the old and ancient class from 1997 with all its limitations.

comment:4 Changed 5 years ago by Mikhail Malyshev

"How did you count the number of 20 pens?"
easy, the 3 images I use for wallpaper use 20 different pens in total

Busy.mcc was just an example when lots of free pens are required.

So, if the images are drawn directly on hi-colour screens,
I guess the major pen consumption is done by some of mcc classes,
even if they do not display anything at the given time.

eg. CyberStorm.mcc picture needs pens?

PS: again, time to play around a bit with palette, I'll see what I find out.

comment:5 in reply to:  4 Changed 5 years ago by Thore Böckelmann

Replying to Michael:

eg. CyberStorm.mcc picture needs pens?

I don't know. That's a 3rd party class and hence beyond our control. If it uses too many pens you must blame somebody else.

Changed 5 years ago by Mikhail Malyshev

Attachment: USED-PENS.PNG added

pens used by images

comment:6 Changed 5 years ago by Mikhail Malyshev

Here we can see that some classes use pens for their logo.
That is why a lot of pens are waisted (all images in black)
Images in colour are either MWB or used direct rendering to screen.

I guess this is out of MUI's control and done by classes themselves ?

https://muidev.de/raw-attachment/ticket/119/USED-PENS.PNG

comment:7 Changed 5 years ago by Thore Böckelmann

The typical prefs image is a compressed IFF body chunk with a fixed 8 color palette. All this is defined by the .mcp class. MUI just remaps the uncompressed bitmap to the supplied palette with a precision of "image". This will reuse similar colors if there is no 100% matching color available. If the best matching color is black, well, then this must be accepted, even if white color is desired.

You are complaining that too many pens are used. Why do you have two bitmap images defined for window and list background which might use lots of pens? Again this is an absolute contradiction to what you are aiming at.

I cannot tell in how far MUI 3.8 did cache bitmap images, but MUI 3.9 will try to cache as many images as possible for fast access, even if the images are currently not used (i.e. no open MUI windows). Since bitmap images are loaded via datatypes.library this means that the corresponding datatypes object is kept alive as long as the image is in the cache. And this means that datatypes.library/picture.datatype will keep the required pens locked as long as the datatypes objects is alive. Images will be flushed only in a low memory situtation. Please note that there isn't something like a "low pen sitation" in AmigaOS which could be triggered to try to free up locked but currently unused pens.

comment:8 Changed 5 years ago by Thore Böckelmann

Resolution: invalid
Status: newclosed

comment:9 Changed 5 years ago by Mikhail Malyshev

You are missing the point again.
The colours were set to black on purpose, to show that they are actually used by the GUI to render the bitmaps. For example Calendar, Cyberstorm image uses direct rendering and does not use any pens and is colourful. Date, MailText on the other side used pens to render their image and since we blancked the colours, they have disappeared.

Background images are rendered directly and do not use pens, so they can be as colourful as you like without any problems.

comment:10 Changed 5 years ago by Thore Böckelmann

Well, and what does this prove, except that the classes with the now black images are using different pens than the ones you would like better? The classes provide suitable colors for their image and MUI just allocates the pen using graphics/ObtainBestPen(). The returned pen number is calculated by graphics.library, not by MUI. If graphics.library thinks that a new pen must be allocated for the requested color instead of reusing a pen with a similar color is the choice of graphics.library. An application can only specify a precision factor which defines how close similar colors must match to be treated as equal. MUI uses a precision of "image" since "exact" would definitely be too much for the simple images. But as long as there are free pens graphics.library is allowed to use as many new pens as it likes if the colors are not similar enough.

comment:11 Changed 5 years ago by Mikhail Malyshev

"Well, and what does this prove,"
It proves that some classes don't use the pens and render the images in colour just fine, while the others use pens, when they should not/or don't ned to do so since they can be drawn direct to screen.
For example the images in the main prefs are all rendered fine and do not use pens. So pointing to colour precision choices of SO is incorrect.

PS: The colours were set to black once they have been already allocated, thus demonstrating that they use pens, if they did not, they would have been unaffected, as some of the images are colourful and untouched by pen changes.

comment:12 in reply to:  11 Changed 5 years ago by Thore Böckelmann

Replying to Michael:

Well, and what does this prove,

It proves that some classes don't use the pens and render the images in colour just fine, while the others use pens, when they should not/or don't ned to do so since they can be drawn direct to screen.

Wrong. It proves that some classes are using different pens than the ones defined for MagicWB. And you are neglecting the fact that the bitmaps are drawn as normal plain 8bit bitmaps which definitely require certain pens to have certain colors. They are not converted to ARGB data to be independent of pens.

For example the images in the main prefs are all rendered fine and do not use pens. So pointing to colour precision choices of SO is incorrect.

That just proves that different images use different pens. The built in images of MUI are ARGB images which of course don't need pens on truecolor screens. But simple 8bit bitmap DO need pens, even on truecolor screens. If the choice of pen numbers is wrong then this is no bug of MUI. Blame your system or a patch you are running.

PS: The colours were set to black once they have been already allocated, thus demonstrating that they use pens, if they did not, they would have been unaffected, as some of the images are colourful and untouched by pen changes.

You should have changed the typical MagicWB colors as well. Currently you are comparing apples with pears. Changing just a few colors proves nothing except that some images use different pens than the MagicWB ones. But this is 100% legal and beyond MUI's scope.

comment:13 Changed 5 years ago by Mikhail Malyshev

You do not understand the point raised.
I am not talking about how the pens are allocated or what's happening.
The question is can we get rid of it and render all these images as ARGB data (as you say). Or it's locked in the code of each mcc, and MUI has no control over it.
And the only thing that can be done is a guide line given to all future mcc's to be written properly with ARGB data in mind.

Using the 8 legacy MWB colours is fine, and it will be the case as long as there are remaining mcc's with old graphics. The only thing that can be done for these if they can not be updated is to have a replacement image placed instead of the build in one.

Any ways, I hope we understood each other, it can't be done since it's the fault of the third party.

comment:14 Changed 5 years ago by Thore Böckelmann

Component: undefinedBitmap.mui
Milestone: MUI 3.9-2014R4
Resolution: invalid
Status: closedreopened

I might consider such a conversion, but I must really think about if it is worth to implement this in MUI 3.9.

However, the bitmap → ARGB conversion comes with a price. It should be done for small bitmaps with 30x30 pixels at most to at least cover the list images. Each image will then consume additional 3.6K of memory although the bitmap consumes just a very few bytes.

comment:15 Changed 5 years ago by Mikhail Malyshev

I think it's a reasonable compromise. Memory is not a big problem these days.
You could also exclude MWB based images, since these use the colours that are always there (or should be). Ofcourse if you can differentiate them. (The coloured images must have a palette entry too, I guess, and that can be a key)

comment:16 Changed 5 years ago by Thore Böckelmann

Owner: set to Thore Böckelmann
Resolution: fixed
Status: reopenedclosed

In 4230:

  • Bitmap.c: bitmaps smaller than 30x30 pixels and with a definite palette (i.e. icons of .mcp classes) are now converted to ARGB data on truecolor screens to allow a penless display. This closes #119.

comment:17 Changed 5 years ago by Thore Böckelmann

Release Notes: modified (diff)

comment:18 Changed 5 years ago by Mikhail Malyshev

Works like a charm. Excellent job!

comment:19 Changed 5 years ago by Thore Böckelmann

Milestone: MUI 3.9-2014R4MUI 3.9-2015R1

Milestone renamed

comment:20 Changed 5 years ago by Thore Böckelmann

Milestone: MUI 3.9-2015R13.9-2015R1

Milestone renamed

Note: See TracTickets for help on using tickets.