Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.acorn.programmer > #1819 > unrolled thread

SWI Wimp_SetCaretPosition and 32k, 64k, 16M colour screen modes

Back to article view | Back to comp.sys.acorn.programmer

Contents

  SWI Wimp_SetCaretPosition and 32k, 64k, 16M colour screen modes chrisbazley@bigfoot.com - 2012-06-23 16:18 -0700
    Re: SWI Wimp_SetCaretPosition and 32k, 64k, 16M colour screen modes Gerph <gerph@gerph.org> - 2012-07-13 08:32 -0700
      Re: SWI Wimp_SetCaretPosition and 32k, 64k, 16M colour screen modes chrisbazley@bigfoot.com - 2012-07-14 03:44 -0700
        Re: SWI Wimp_SetCaretPosition and 32k, 64k, 16M colour screen modes Martin Wuerthner <spamtrap@mw-software.com> - 2012-07-18 00:11 +0200

#1819 — SWI Wimp_SetCaretPosition and 32k, 64k, 16M colour screen modes

I am trying to update an old application to be compatible with the 64 thousand colour screen modes introduced by RISC OS 6. In the process, I noticed that the caret colour is wrong - not only in 64k colour modes, but also in older 32k and 16M colour modes.

The application allows the background and caret colours to be chosen separately from the standard 16 Wimp colours. The colour passed to Wimp_SetCaretPosition in bits 16-23 of R4 is computed by EOR-ing the background and caret colours together, to ensure that the caret appears correct when plotted with EOR action. 

In screen modes with fewer than 256 colours, this trick doesn't even require bit 27 of R4 to be set (use GCOL). In 256 colour modes, the Wimp palette must be read by the program beforehand, used to translate the two Wimp colours to GCOLs before EOR-ing them together, and bit 27 must be set.

However, I can't see any interface to specify a 15-, 16- or 24-bit caret colour.

From experimentation in screen modes with more than 256 colours, it seems that the window manager ignores the colour specified in bits 16-23 of R4 on entry to SWI Wimp_SetCaretPosition. Instead, it always uses colour 11 (red, HTML colour #dd0000), which makes the caret difficult to see if the result of EOR-ing red with the background has low contrast. Effectively, it rules out all background colours except for white!

Passing a Wimp colour to Wimp_SetCaretPosition (i.e. bit 27 of R4 is clear) doesn't work in high colour modes either. Presumably this isn't supported because plotting with EOR action operates on OS_SetColour numbers rather than Wimp_SetColour numbers, therefore it would be difficult to predict which Wimp colour (if any) will produce the correct result after being translated to an RGB triplet.

Please can anyone confirm that the window manager was never extended to allow caret colours to be specified in 32k and 16M colour screen modes? How on Earth did Acorn overlook this in RISC OS 3.5?

I wonder whether there is any mileage in converting all Wimp palette entries to colour numbers in the current mode, EOR-ing each potential converted caret colour with the converted background colour, using a weighted least-squares algorithm to find the best match with the requested caret colour, and using the Wimp colour which yielded that result!

Whoever decided to pack the caret colour into the same register as the height and flags, despite knowing that the OS provided for 24 bit palette entries, should be shot! I can't believe that such short-sighted register usage yielded significant performance benefits.

Chris Bazley

[toc] | [next] | [standalone]

#1927

On 24 June, 00:18, chrisbaz...@bigfoot.com wrote:
> I am trying to update an old application to be compatible with the 64 thousand colour screen modes introduced by RISC OS 6. In the process, I noticed that the caret colour is wrong - not only in 64k colour modes, but also in older 32k and 16M colour modes.

I'm pretty sure I left it in a working state. Certainly here on 4.43
it's working correctly in 32k and 16M modes. ColourTrans 1.90,
WindowManager 6.40. Although my test here is only for the default
colour, not for colour selection by wimp palette.

> The application allows the background and caret colours to be chosen separately from the standard 16 Wimp colours. The colour passed to Wimp_SetCaretPosition in bits 16-23 of R4 is computed by EOR-ing the background and caret colours together, to ensure that the caret appears correct when plotted with EOR action.
>
> In screen modes with fewer than 256 colours, this trick doesn't even require bit 27 of R4 to be set (use GCOL). In 256 colour modes, the Wimp palette must be read by the program beforehand, used to translate the two Wimp colours to GCOLs before EOR-ing them together, and bit 27 must be set.
>
> However, I can't see any interface to specify a 15-, 16- or 24-bit caret colour.
>
> From experimentation in screen modes with more than 256 colours, it seems that the window manager ignores the colour specified in bits 16-23 of R4 on entry to SWI Wimp_SetCaretPosition. Instead, it always uses colour 11 (red, HTML colour #dd0000), which makes the caret difficult to see if the result of EOR-ing red with the background has low contrast. Effectively, it rules out all background colours except for white!
>
> Passing a Wimp colour to Wimp_SetCaretPosition (i.e. bit 27 of R4 is clear) doesn't work in high colour modes either. Presumably this isn't supported because plotting with EOR action operates on OS_SetColour numbers rather than Wimp_SetColour numbers, therefore it would be difficult to predict which Wimp colour (if any) will produce the correct result after being translated to an RGB triplet.
>
> Please can anyone confirm that the window manager was never extended to allow caret colours to be specified in 32k and 16M colour screen modes? How on Earth did Acorn overlook this in RISC OS 3.5?
>
> I wonder whether there is any mileage in converting all Wimp palette entries to colour numbers in the current mode, EOR-ing each potential converted caret colour with the converted background colour, using a weighted least-squares algorithm to find the best match with the requested caret colour, and using the Wimp colour which yielded that result!
>
> Whoever decided to pack the caret colour into the same register as the height and flags, despite knowing that the OS provided for 24 bit palette entries, should be shot! I can't believe that such short-sighted register usage yielded significant performance benefits.

I remember looking into this when I updated the API to support 256
colour modes with fully specified palettes. The fact that the API
doesn't support the full width colours isn't an easy one to fix,
because the width of the API is not elastic enough to allow the
addition of the extra colour detail. Anyone intending to preserve the
caret details would only preserve the registers R0-R5
(win,icon,x,y,height-and-flags,index), so the addition of any other
parameter would be lost.

The flags themselves are already the way that the colour is wedged
into the API as part of the height.

The extended cut-and-paste selection model API for the call could have
extended it, but this would still prevent older clients from retaining
the colouring - resulting in restored carets having the wrong colour
when returned by older applications.

I think (although I cannot be certain because my notes don't indicate
anything about the use of wider colours) that I probably decided at
the time that it wasn't worth extending much further for true colour
because it would not work reliably. I added support for changing the
default caret colour, but that's the only change that was made in that
area, I believe.

Sorry.

--
Gerph
... To live without my music would be impossible do
    In this world of troubles my music pulls me through.

[toc] | [prev] | [next] | [standalone]

#1928

On Friday, July 13, 2012 4:32:14 PM UTC+1, Gerph wrote:
> On 24 June, 00:18, chrisbaz...@bigfoot.com wrote:
> > I am trying to update an old application to be compatible with the 64 thousand colour screen modes introduced by RISC OS 6. In the process, I noticed that the caret colour is wrong - not only in 64k colour modes, but also in older 32k and 16M colour modes.
> 
> I'm pretty sure I left it in a working state. Certainly here on 4.43
> it's working correctly in 32k and 16M modes. ColourTrans 1.90,
> WindowManager 6.40. Although my test here is only for the default
> colour, not for colour selection by wimp palette.

It 'works' - just not in a useful way from the point of view of an application programmer using the caret on a coloured background.

Presumably changing the default caret colour would be very bad manners, although it might be a solution if I could figure out the colour number that would produce my desired colour when Eor-plotted against my background, and conver that to whatever encoding the default caret colour is specified in.

I am slightly surprised that you can't specify a Wimp colour in modes with more than 256 colours, although it wouldn't be very useful (just as it isn't in modes with 256 colours).

> > Whoever decided to pack the caret colour into the same register as the height and flags, despite knowing that the OS provided for 24 bit palette entries, should be shot! I can't believe that such short-sighted register usage yielded significant performance benefits.
> 
> I remember looking into this when I updated the API to support 256
> colour modes with fully specified palettes. The fact that the API
> doesn't support the full width colours isn't an easy one to fix,
> because the width of the API is not elastic enough to allow the
> addition of the extra colour detail. Anyone intending to preserve the
> caret details would only preserve the registers R0-R5
> (win,icon,x,y,height-and-flags,index), so the addition of any other
> parameter would be lost.

Oh, I didn't think about that use case. I suppose it's a fundamental flaw of every state-preservation mechanism that uses a fixed number of bits that can't be queried. Maybe what is really required is a caret 'stack' like OpenGL matrix stacks.

> The flags themselves are already the way that the colour is wedged
> into the API as part of the height.
> 
> The extended cut-and-paste selection model API for the call could have
> extended it, but this would still prevent older clients from retaining
> the colouring - resulting in restored carets having the wrong colour
> when returned by older applications.
> 
> I think (although I cannot be certain because my notes don't indicate
> anything about the use of wider colours) that I probably decided at
> the time that it wasn't worth extending much further for true colour
> because it would not work reliably. I added support for changing the
> default caret colour, but that's the only change that was made in that
> area, I believe.
> 
> Sorry.

No need to be sorry. It sounds like fixing it would have been impossible. I dare say Acorn came to the same conclusion. I was just wondering whether there is an established work-around for what must surely be a very common problem.

Cheers,

Chris Bazley

[toc] | [prev] | [next] | [standalone]

#1933

In message <07be8c27-8960-4185-b2fd-5ca22e36aa9d@googlegroups.com>
          chrisbazley@bigfoot.com wrote:

> On Friday, July 13, 2012 4:32:14 PM UTC+1, Gerph wrote:

>> I think (although I cannot be certain because my notes don't indicate
>> anything about the use of wider colours) that I probably decided at
>> the time that it wasn't worth extending much further for true colour
>> because it would not work reliably. I added support for changing the
>> default caret colour, but that's the only change that was made in that
>> area, I believe.
>> 
>> Sorry.

> No need to be sorry. It sounds like fixing it would have been
> impossible. I dare say Acorn came to the same conclusion. I was just
> wondering whether there is an established work-around for what must
> surely be a very common problem.

Yes, set bit 25 to make the caret invisible and redraw it in the 
application's redraw handler.

-- 
Martin
---------------------------------------------------------------------
Martin Wuerthner         MW Software      http://www.mw-software.com/
        RISC OS Software for Design, Printing and Publishing
---------------------------------------------------------------------

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.acorn.programmer

csiph-web