Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#245 closed enhancement (fixed)

Get rid of AfA OS dependency on OS3

Reported by: Andreas Falkenhahn Owned by: Thore Böckelmann
Priority: normal Milestone: 4.0-2015R3
Component: Text.mui Version: 4.0-nightly build
Severity: minor Keywords:
Cc: OS Platform: AmigaOS3
Blocked By: Blocking:
Release Notes:

Description

Currently, direct RGB drawing using \33P[RRGGBB] on OS3 is only supported when AfA OS patches are installed which is pretty annoying because no one wants to install a bunch of hacky and experimental patches just to get support for direct RGB drawing.

Thus, MUI should do direct RGB drawing in the proper way. Instead of using alien APIs backported from AROS, MUI should draw text to rastports by doing it the CGX/P96 way: Simply allocate a single *exclusive* pen using ObtainPen() and PEN_EXCLUSIVE. Then, whenever you need to draw something using Text(), just set this pen to the desired color and draw the text.

That's the proper way to draw RGB text with CGX/P96 and is a much better solution than forcing people to install heaps of patches just to get something rather trivial like RGB text.

Change History (10)

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

Owner: set to Thore Böckelmann
Priority: undecidednormal
Status: newassigned

comment:2 Changed 4 years ago by Thore Böckelmann

Resolution: fixed
Status: assignedclosed

In 4911:

  • mastergfx.c, mastertext.c: allocate an exclusive pen for truecolor screens. This makes it possible to use direct RGB pens on truecolor screens without having to install patches like AfAOS. This closes #245.

comment:3 Changed 4 years ago by Mikhail Malyshev

https://muidev.de/attachment/ticket/255/mui.PNG

interesting, the support link to muidev site in about window.

it's blue in 8 bit or less screenmodes, and white on 16/32 bits,
anything forgotten with the new colour allocation process ?

comment:4 Changed 4 years ago by Thore Böckelmann

Works perfectly here for me. And your screenshot belongs to a completely unrelated ticket.

comment:5 Changed 4 years ago by Mikhail Malyshev

The screenshot shows a few things. The SUPPORT link refers to this ticket.
As far as I understand, that link should be coloured (on the pic it's white)
And it's colour changes on 8bit and true colour screens, so it's not consistent here. That's why I asking if there is something going wrong here.

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

Replying to Michael:

The screenshot shows a few things. The SUPPORT link refers to this ticket.
As far as I understand, that link should be coloured (on the pic it's white)

Then you understood wrong. The "Support" link is intentionally white with shadow outline. The "MUI Bugtracker" link has the default color one can configure for Hyperlink.mcc. But note that the outline color of the "Support" link is set as an RGB color, not as a specific pen. Such things cannot work on colormapped screens and hence the default pen of Hyperlink.mcc for non-hovered links becomes visible. Obtaining a pen for that RGB color isn't possible either, because as soon as it is released again it might be obtained by another application which sets a completely different color which in turn will recolor the link text again.

And yes, I can guess your next complain or request already. Why do I use a white RGB color when I could use the system SHINE pen, which is white as well, and which works on colormapped screens as expect? The answer is simple: it is usually white, but this is no guarantee. And having something correct "most of the time" is as bad as being always wrong. Choosing a pen whose RGB values are as close as possible doesn't work either, because as long as the pen is not under the control of MUI it may be changed at any time, resulting in even more wrong colors.

And it's colour changes on 8bit and true colour screens, so it's not consistent here. That's why I asking if there is something going wrong here.

There is nothing wrong here. You are just facing one more situation where colormapped screens cannot give you the same feature set as truecolor screens. No matter what color or pen I set it will always be wrong in certain situations. Colormapped screens really belong to the past. How many times did I say this by now? And how many times did you ignore this already?

And finally this ticket was about getting rid of AfAOS as a requirement to display text using direct RGB colors on a truecolor screen. Nobody, except you, ever talked about support for arbitrary RGB color support on colormapped screens. This is not going to work, no matter how often you ask for it.

comment:7 Changed 4 years ago by Mikhail Malyshev

No problems with me here :-)
Just wondered if it was something fishy.
So your detailed explanation is acceptable.
And it works, that's the important part (just a bit different in different conditions).

comment:8 Changed 4 years ago by Mikhail Malyshev

РHmmm… Still puzzled…
On 8bit screen, it's blue, and changes colour when pointed at. (uses Hyperlink setting colours)
On 16+bit screen, it's always white, including highlight and when clicked. (so my question is, is it internationally always white ? )

comment:9 Changed 4 years ago by Mikhail Malyshev

" The "Support" link is intentionally white with shadow outline. "
What colour is supposed to be the shadow ? Mid grey or black ?

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

Replying to Michael:

РHmmm… Still puzzled…
On 8bit screen, it's blue, and changes colour when pointed at. (uses Hyperlink setting colours)

Sigh… Yes, because the RGB white cannot be handled on colormapped screen. And in that case the last available pen is the one set by Hyperlink.mcc as usual preparse string to change the link color. Exactly like it is done for any other link. Get it. The RGB white color is simply ignored and your are seeing a link being colored as you configured it. The only addition is the outline, which Hyperlink.mcc does not override.

On 16+bit screen, it's always white, including highlight and when clicked. (so my question is, is it internationally always white ? )

Yes, because on truecolor screens the intented white color will always override any color set by Hyperlink.mcc.

What colour is supposed to be the shadow ? Mid grey or black ?

That depends on what your system uses as SHADOW and HALFSHADOW pens. By default the SHADOW pen will be used, unless it is the same as the TEXT pen. In that case the HALFSHADOW pen will be used. Usually this should be some shade of grey, not black. Look at your own screenshot. It is definitely NOT black.

This will be my last comment to this ticket, unless there is something else to be done regarding its topic. This ticket is NOT about color issues on colormapped screens!

Note: See TracTickets for help on using tickets.