Bounty proposal: Paint

I may be missing the point (since I don’t mind the 4×4 weird layout of 256), but could the artist-friendly thing be dealt with by just re-ordering the colours window to not be in ascending colour number order?

Until you try to edit a palette, that’s exactly what the current code does. The colour numbers are displayed in a non-ascending sequence.

That would allow you to pick the colour in an artist-friendly way, but the underlying sprite would still be in weird order which is helpful to avoid needing a custom palette or ColourTrans table (so making sprites smaller/faster to plot). I don’t see any reason to shuffle pixels or similar as long as the colours are the default RISC OS palette.

Yeah we haven’t really got any problem with the default RISC OS palette because it’s easy to detect and everyone’s happy that every colour will fit perfectly into the hard-coded artist-friendly sequence. It’s when people start editing one or more colours, or loading other palettes, that the differences of opinion have arisen here.

You could even have other views. Menu click on the colours window and choose from: artist-friendly, weird VIDC, luminance, or any other arbitrary sort order in the colours window.

Yes that would be great, but someone would have to find the time to code it. :-)

I may be missing the point (since I don’t mind the 4×4 weird layout of 256), but could the artist-friendly thing be dealt with by just re-ordering the colours window to not be in ascending colour number order?

Until you try to edit a palette, that’s exactly what the current code does. The colour numbers are displayed in a non-ascending sequence.

I thought it was fast but didn’t dig deeper.

I don’t see any reason to shuffle pixels or similar as long as the colours are the default RISC OS palette.

Yeah […] It’s when people start editing one or more colours, or loading other palettes, that the differences of opinion have arisen here.

Got it. In which case:

• If the sprite didn’t have a custom palette attached and I went to edit a colour, I’m already beyond the point of no return (because a palette is going to be added) so Paint is free to rejig the pixels at the same time.
• If the sprite already had a custom palette and I was editing one, then no pixels to reorganise anyway.

In both cases the ‘Edit palette >’ warning seems like a distraction, in my opinion. But I’m neither an artist nor artistic!

If the sprite didn’t have a custom palette attached and I went to edit a colour, I’m already beyond the point of no return (because a palette is going to be added) so Paint is free to rejig the pixels at the same time.

Ah, OK. That’s a little different to the limited understanding I picked up from Jeffrey’s comments earlier in the discussion:

Surely once you’ve added an explicit palette to the sprite, even if it’s in exactly the same order as the standard palette definition, you’ve already had the performance drop?

Not really. ColourTrans caches the translation tables that are generated for plotting things in palletised modes, so it should spot that the explicitly defined default palette used by the sprite matches the implicitly defined 256 colour default palette and will reuse translation tables where appropriate.

For plotting in 256 colour modes using the default palette, if the caller didn’t spot that the palette/translation table wasn’t required then SpriteExtend has its own checks to detect and discard identity translation tables – so it should still be (just about) as fast as if there was no palette. Certainly a lot faster than if a custom palette was used (n.b. I haven’t timed this myself!)

For some reason I assumed from this that there are performance gains to be had even if, say, one or two colours have been edited from the default palette although I now see he didn’t say that. If you edit one colour in the default palette, does it have to build a translation table with entries for every colour or just the colour that changed?

If you edit one colour in the default palette, does it have to build a translation table with entries for every colour or just the colour that changed?

It’ll build a translation table for the entire palette.

You could even have other views. Menu click on the colours window and choose from: artist-friendly, weird VIDC, luminance, or any other arbitrary sort order in the colours window.

I’m warming to this idea a bit. If we can reach a consensus that remapping the sprite’s palette data to reorder the colours isn’t very useful, then changing the feature to just be a configurable sort order on the colours window might be the best way forward.

If we went that route, one bit I haven’t completely decided is to what degree Paint should remember (in Paint$Options) the colours window sort order the user selected. It could remember a setting for each of the standard palette types but then what should it do when you load a sprite? You’d then have to detect if the palette was colour or greyscale for example (test the saturations?).

Menu click on the colours window

+1 to this.

Whatever you decide about the actual options here, Andy, it might be worth thinking whether all these various palette functions (edit palette, view small/big colours, your new advanced submenu, etc) ought to be shifted into a new menu in the Colours window, rather than in the Edit submenu over the main sprite window. As Rick pointed out, it’s not very intuitive to select a colour in the Colours window, then open the menu in the Sprite window to edit it. Paint’s idiosyncratic menu structure predates the Style Guide by a long way, so I don’t think changing it to a more logical grouping would necessarily be a problem.

It’ll build a translation table for the entire palette.

Thanks Jeffrey. Given there’s always a performance hit from editing one or more colours in the palette then, I’m thinking the very short term solution for this is to just disable that Edit Palette remap dialogue box by default (which currently means the pixels just get remapped to artist-friendly without asking, provided the artist-friendly option is enabled).

A longer term and better solution is I believe optional algorithmic sorting of the colours window. Rearranging palettes can then be left to other programs.

I need to have a closer look at it, but I suspect even the artist-friendly layout Michael provided can be arrived at algorithmically.

It’s all the same colours as normal, just moved to different places. The groupings are:

Grayscales (top)

A continuous graduation of 16 greys.

Bright colours (bottom left)

18 continuous graduations, each of four colours.

Muted colours (bottom right)

Six continuous graduations, each of 12 colours. (Perhaps reversing the middle row of each 4×3 block would be better?)

Intermediate colours (upper)

12 continuous graduations, each of 8 colours.

Each colour section is arranged circularly by hue, with red at top left.

Something like removing all greys to place at the top, then sorting all the remaining colours by saturation then hue, then splitting that result into four six or eight groups, then sorting each group again by hue then by luminance. If that can produce the same layout or something close to that layout, then we’d no longer need to worry about how to deal with edited palettes. It might give odd results if someone loaded a greyscale palette but as mentioned previously a test for maximum saturation could detect that and disable the artist-friendly layout.

Time for a quick update while I drink this coffee! Paint 2.28 includes:

• Keyboard shortcuts for the sprite windows
• The outstanding “Selection, zoom and resize” tasks except for the toolbox button for Add/remove row/columns, as the latter can now be invoked using function keys (and it would have needed yet another redesign of the button layout, changing the artwork of the edge buttons).
• The “click of surprise” fix is in as well, with the need for an extra click to set input focus being configurable on the Paint menu.
• For the artist-friendly colours feature, I’ve added a setting and changed the default behaviour based on your feedback. By default, the controversial dialogue box for remapping palettes is not shown when you edit the palette. The new setting, “Rearrange user palettes” toggles artist-friendly arranging of user-edited palettes and you won’t be prompted for this unless the “Confirm rearranging palette” option is also ticked.

If, like Chris, you don’t want non-default palettes to be rearranged at all, just untick “Rearrange user palettes” and save a Desktop Boot file (making sure Paint isn’t buried in too deep a path).

There’s unfortunately a bug in 2.28 whereby remapping to artist-friendly doesn’t happen even if “Rearrange user palettes” is ticked.¹ You can work around it for now by enabling “Confirm rearranging palette” if you need it. I’ve already sent ROOL a fix for this. Edit: They’ve now added the fix to 2.28.

Another known bug is Ctrl-P to Edit Palette sometimes fails with the error “submenus require a parent menu tree”. It’s because RISCOS_Lib’s dboxtcol colour picker always opens in submenu mode. I’m discussing a fix with ROOL currently.

^{1 Late last night it was a case of two bugs conspiring to make it look like the feature was working and then me only managing to fix one of them! Sorry about that.}

This bit of business may predate the bounty.

I did notice a zoom oddity in !Paint 2.28, 2.27 and 2.26 in transparent areas when the grid is enabled, but !Paint 2.17 31-Jul-14 from OS5.22 also shows the issue.

The grid horizontal lines are not displayed when the zoom ratio is an even number to one and with an odd numbered ratio a thick grid line is drawn every two rows.

Here is a simple test sprite, just CTRL-drag resize or CTRL-scroll to see the full range of effects.

David, meet Moiré Interference, Moiré, David.

The lines are drawn, and are all the same width.

Here they are, in red:

I’d argue that in 2019 Paint shouldn’t be using a crap black and white ECF to indicate transparency, but what do I know.

Moiré

I should not have chosen black text!!!!

Selected red as the grid colour shows the interaction between the grid lines and transparency lines. For some reason Snapper took a huge area snap of adjacent odd and even sprite windows which very clearly shows the issue.

With black grid lines the grid either overlays the transparency line and ‘appears’ not to be there or it falls between two transparency lines making a three thickness line.

Late last night it was a case of two bugs conspiring to make it look like the feature was working and then me only managing to fix one them! Sorry about that.

Well, anyone would think it was in a beta release… Oh, so it is.
That’s what tests and testers are for.

Thanks, Andy, for all the work you’re putting in.

+1 for the hard work, Andy!

You’re welcome guys. I’m as pleased as you are, I expect, to see these new features working at last.

Selected red as the grid colour shows the interaction between the grid lines and transparency lines. For some reason Snapper took a huge area snap of adjacent odd and even sprite windows which very clearly shows the issue.

With black grid lines the grid either overlays the transparency line and ‘appears’ not to be there or it falls between two transparency lines making a three thickness line.

On the above snapshots, you’ve left the grid on when you view them, so Paint is showing two grids: the one from the original image and the one in the current instance of Paint, which makes it look a bit confusing. The important thing is that the large (original) grid lines are all the same thickness (actually 16 pixels on your image).

It’s worth noting that some zoom ratios mean the number of on-screen pixels needed to display one sprite pixel is not a whole number. For example, at 9:2, each sprite pixel would correspond to 4.5 screen pixels. That means short of using anti-aliasing, it’s not possible to make the spaces between the grid lines all the same size at such zoom ratios. That won’t affect the thickness of the actual grid lines though.

Edit: I realise you’re concerned with grid lines moving in and out of phase with the transparency pattern. As nemo says, that is the Moiré effect and is unavoidable with that striped transparency pattern.

Regarding palette editing, I haven’t tried the updated Paint yet (is there a stand-alone older-OS build?), but for the purposes of inspiration or amusement here’s an 800KB GIF of my palette editor, and in deference to Rick’s piece of French wet string, a less interesting still:

(is there a stand-alone older-OS build?)

The one hiding inside !Boot.RO350Hook.Apps in the Nightly Beta HardDisc4 download should work.

EDIT: Just tried it on RO3.7 and it doesn’t work. “Shared C library out of date”. Ho hum.

Well it didn’t do that on 4.37. No.

Instead it exploded with “SpriteExtend: No such sprite”. Trying to drag anything in the file window triggers that. Paint really is the most fragile pile of coincidence that ever shipped with RO. It’s always been painful. At least the RO4 version dumps your files in !Scrap when it throws a hissy fit, which this version pointedly did not do. Bye, work.

The little scrollbar colour indicator is thrashing on resize, which is a bit odd as redraw isn’t required. It’s to do with the pointer coordinates not being updated (but it ought to be a child window so shouldn’t need any help from the code – something wrong there).

It’s a pity Paint still doesn’t cope with generalised palette files. The insistence on certain lengths and assuming the internal ordering instead of looking at the actual contents has always been daft. I blame the Wimp (but who uses Wimp palettes now?), which goes to the trouble of checking that the nth entry is for colour n and complains otherwise (because if it was actually colour m well there’d be no way of knowing…oh hang on).

The “transparency” background should not scale with the sprite. (The stripes are dreadful anyway, ECFs are not useful in deep colour modes).

Describing 16- and 64- entry palettes on 256 colour sprites as “old” is unhelpful – they’re two different sizes. One is an old sprite palette but the other is an old screen palette. Better terminology needed really.

RO4’s version of SpriteExtend gets 32k colour sprites wrong in 16M colour modes (it accidentally makes them 4% darker, and yes you absolutely can tell). I haven’t checked RO6, but it is possible to fix it using a colour map function.

(Aside: I am currently mitigating SpriteExtend’s dreadful murdering of CMYK sprites by using a colour mapping function, which ought to be horrifying if you know how SpriteExtend works)

Just tried it on RO3.7 and it doesn’t work. “Shared C library out of date”. Ho hum.

You may need to update your CLib module to get it to run on RISC OS 3.7 or older. At the moment I’m not sure exactly what causes that message to appear from Paint. The message is generated by the CLib stub rather than Paint itself. Possibly the stub version that Paint is built against requires a minimum CLib version but at the moment I’m not sure what version that would be. :(

I can run Paint successfully on RISC OS 3.5 with SharedCLibrary 5.86 (30 Jun 2015) which I copied into my !Boot so it’s certainly possible. You may need to get a recent version of SprExtend as well.

Well it didn’t do that on 4.37. No.

Instead it exploded with “SpriteExtend: No such sprite”. Trying to drag anything in the file window triggers that.

Hmm. What version of SpriteExtend are you running?

At least the RO4 version dumps your files in !Scrap when it throws a hissy fit, which this version pointedly did not do. Bye, work.

The !Scrap saving code is still there, so I guess it didn’t even make it that far!

The little scrollbar colour indicator is thrashing on resize, which is a bit odd as redraw isn’t required. It’s to do with the pointer coordinates not being updated (but it ought to be a child window so shouldn’t need any help from the code – something wrong there).

Yeah, the redraw logic is pretty dumb at the moment. It’s basically being paranoid about the potential for the window furniture to change size on an open window request with the result that the colour indicator dimensions are recalculated and it gets redrawn on every such request. I can’t remember if you can change the furniture icons of open windows but a screen mode change can certainly alter the dimensions. I didn’t worry about it too much as they’re such small rectangles being redrawn but the flicker is a bit unpleasant.

The “transparency” background should not scale with the sprite.

I don’t think it should either. How are you getting it to do that, though?

(The stripes are dreadful anyway, ECFs are not useful in deep colour modes).

What pattern would you prefer? Cross-hatching?

Describing 16- and 64- entry palettes on 256 colour sprites as “old” is unhelpful – they’re two different sizes. One is an old sprite palette but the other is an old screen palette. Better terminology needed really.

Where are they being referred to as “old”? Is it a !Help message?

Hmm. What version of SpriteExtend are you running?

RISC OS 4.39 (28th April 2004) would be running SpriteExtend 1.57 (4th May 2004) – does this help? That is the most up to date version of VRPC Adjust so is an obvious candidate for testing.

The SpriteExtend error is readily reproducible on OS4.39 RPCEmu. I do get the save to WimpScrap here. SpriteExtend 1.83 from OS5.27 RPCEmu did not help.

On a Titanium.

RISC OS 5.27 (01 Oct 2019)
*help !Paint
==> Help on keyword !Paint
Module is: !Paint          2.28 (26 Sep 2019)

Create a new sprite then start a drag in the Sprite file window. Ouch.

Time: Mon Oct  7 14:01:28 2019
Location: Offset 0001ca2c in module !Paint
Current Wimp task: Paint
Last app to start: TaskWindow 4360397C 00000002  -ctrl

R0  = 00000000 R1  = 00000000 R2  = 240d3ae4 R3  = 00000000
R4  = 00000005 R5  = 00000060 R6  = 204c87ec R7  = 204c87ec
R8  = 00009d50 R9  = 00000000 R10 = 00008230 R11 = 00009d88
R12 = 00000000 R13 = 00009d48 R14 = 00009d60 R15 = fc3f21ac
DFAR = 00000004  Mode USR32  Flags nZCv if   PSR = 60000010

fc3f2164 : e24dd028 : SUB     R13,R13,#&28       ; ="("
fc3f2168 : e1a0e00d : MOV     R14,R13
fc3f216c : e3a01000 : MOV     R1,#0
fc3f2170 : e3a02000 : MOV     R2,#0
fc3f2174 : e3a03000 : MOV     R3,#0
fc3f2178 : e3a07000 : MOV     R7,#0
fc3f217c : e3a08000 : MOV     R8,#0
fc3f2180 : e3a0c000 : MOV     R12,#0
fc3f2184 : e8ae118e : STMIA   R14!,{R1-R3,R7,R8,R12}
fc3f2188 : e88e008e : STMIA   R14,{R1-R3,R7}
fc3f218c : e59f111c : LDR     R1,&FC3F22B0
fc3f2190 : e51a2218 : LDR     R2,[R10,#-536]
fc3f2194 : e28d8008 : ADD     R8,R13,#8
fc3f2198 : e3500000 : CMP     R0,#0
fc3f219c : e0827001 : ADD     R7,R2,R1
fc3f21a0 : e5971008 : LDR     R1,[R7,#8]
fc3f21a4 * e5911004 * LDR     R1,[R1,#4]
fc3f21a8 : e88d0012 : STMIA   R13,{R1,R4}
fc3f21ac : e2871024 : ADD     R1,R7,#&24         ; ="$"
fc3f21b0 : e891500c : LDMIA   R1,{R2,R3,R12,R14}
fc3f21b4 : e888500c : STMIA   R8,{R2,R3,R12,R14}
fc3f21b8 : 0a000010 : BEQ     &FC3F2200
fc3f21bc : e59d1008 : LDR     R1,[R13,#8]
fc3f21c0 : e5902000 : LDR     R2,[R0,#0]
fc3f21c4 : e0813002 : ADD     R3,R1,R2
fc3f21c8 : e58d3008 : STR     R3,[R13,#8]
fc3f21cc : e59d1010 : LDR     R1,[R13,#16]
fc3f21d0 : e5902000 : LDR     R2,[R0,#0]
fc3f21d4 : e0813002 : ADD     R3,R1,R2
fc3f21d8 : e58d3010 : STR     R3,[R13,#16]
fc3f21dc : e59d100c : LDR     R1,[R13,#12]
fc3f21e0 : e5902004 : LDR     R2,[R0,#4]

R15 = fc3f21ac = !Paint +1ca34
R14_usr = 00009d60 = +1d60 in application memory

USR stack:
00009d48 : 00000000 :
00009d4c : 00000000 :
00009d50 : 00000000 :
00009d54 : 00000000 :
00009d58 : 00000000 :
00009d5c : 00000000 :
00009d60 : 00000000 :
00009d64 : 00000000 :
00009d68 : 00000000 :
00009d6c : 00000000 :
00009d70 : 00016db8 : - R4
00009d74 : 00000060 : | R7
00009d78 : 000004af : | R8
00009d7c : 00009dac : | R11
00009d80 : 00009d8c : | R12
00009d84 : fc3f28f4 : | R14: fc3f28f4
         :          : | = !Paint +1d17c
00009d88 : fc3f215c : | APCS function: fc3f2154
         :          : | = !Paint +1c9dc
00009d8c : 00016db8 : | R4
00009d90 : 00009e40 : | R5
00009d94 : 00009e44 : | R6
00009d98 : 00000001 : | R7
00009d9c : 00000006 : | R8
00009da0 : 00009e04 : | R11
00009da4 : 00009db0 : | R12
00009da8 : fc3dc414 : | R14: fc3dc414
         :          : | = !Paint +6c9c
00009dac : fc3f27a4 : | APCS function: fc3f279c
         :          : | = !Paint +1d024
00009db0 : 00000001 : |
00009db4 : 00000000 : |
00009db8 : 00000000 : |
00009dbc : ffffff08 : |
00009dc0 : 000000cf : |
00009dc4 : 00000000 : |
00009dc8 : 00000000 : |
00009dcc : 00000000 : |
00009dd0 : 00009e04 : |                                          - R11
00009dd4 : 00009de0 : |                                          | R12
00009dd8 : fc3dc1c8 : |                                          | R14: fc3dc1c8
         :          : |                                          | = !Paint +6a50
00009ddc : fc15b560 : |                                          | APCS function: fc15b558
         :          : |                                          | = SharedCLibrary +152c8
         :          : |                                          | = bbc_inkey +4
00009de0 : 204c7dd9 : | R4                                       |
00009de4 : 00009e40 : | R5                                       |
00009de8 : 204caed0 : | R6                                       |
00009dec : 0000000b : | R7                                       |
00009df0 : 204ca868 : | R8                                       |
00009df4 : fc3d8ac8 : | R9                                       |
00009df8 : 00009e20 : | R11                                      |
00009dfc : 00009e08 : | R12                                      |
00009e00 : fc174594 : | R14: fc174594                            |
         :          : | = SharedCLibrary +2e304                  |
         :          : | = win_processevent +180                  |
00009e04 : fc3dbca0 : | APCS function: fc3dbc98                  ? Broken APCS chain?
         :          : | = !Paint +6520
00009e08 : 00009e40 : | R4
00009e0c : 00000000 : | R5
00009e10 : 240d3ae4 : | R6
00009e14 : 00009e3c : | R11
00009e18 : 00009e24 : | R12
00009e1c : fc15d688 : | R14: fc15d688
         :          : | = SharedCLibrary +173f8
         :          : | = event__process +248
00009e20 : fc174420 : | APCS function: fc174418
         :          : | = SharedCLibrary +2e188
         :          : | = win_processevent +4
00009e24 : 00000000 : | R4
00009e28 : 0000a284 : | R5
00009e2c : 00000000 : | R8
00009e30 : 00009f50 : | R11
00009e34 : 00009e40 : | R12
00009e38 : fc15d7e8 : | R14: fc15d7e8
         :          : | = SharedCLibrary +17558
         :          : | = event_process +3c
00009e3c : fc15d44c : | APCS function: fc15d444
         :          : | = SharedCLibrary +171b4
         :          : | = event__process +4
00009e40 : 00000006 : |
00009e44 : 000000d8 : |
00009e48 : 00000260 : |
00009e4c : 00000040 : |
00009e50 : 204c7dd9 : |
00009e54 : ffffffff : |
00009e58 : 00000004 : |
00009e5c : ffffffff : |
00009e60 : 00000000 : |
00009e64 : 00000000 : |
00009e68 : 00000004 : |
00009e6c : 00000fff : |
00009e70 : ffffffff : |
00009e74 : 45676e6f : |
00009e78 : 69442444 : |
00009e7c : 212e3e72 : |
00009e80 : 006e7552 : |
00009e84 : 4553212e : |
00009e88 : 006f675f : |
00009e8c : 00000302 : |
00009e90 : 00000918 : |
00009e94 : 00009ea0 : |
00009e98 : 00009eb8 : |
00009e9c : 000178d0 : |
00009ea0 : 000000c0 : |
00009ea4 : 00009efc : |
00009ea8 : 00000002 : |
00009eac : 00000002 : |
00009eb0 : 00000001 : |
00009eb4 : fc160b58 : |                                          - fc160504 return to fc160b58?
         :          : |                                          | fc160504 = SharedCLibrary +1a274
         :          : |                                          | = sprite__op +0
         :          : |                                          | fc160b58 = SharedCLibrary +1a8c8
         :          : |                                          | = sprite_readsize +30
00009eb8 : 00000228 : |
00009ebc : fc0946bc : |
00009ec0 : fc09b350 : |
00009ec4 : 00009f1c : |
00009ec8 : 00009f00 : |
00009ecc : 00000000 : |
00009ed0 : 00009ef0 : |
00009ed4 : 00009f2c : |                                          - R4
00009ed8 : 0000a284 : |                                          | R5
00009edc : 240d3ae4 : |                                          | R6
00009ee0 : 00000000 : |                                          | R7
00009ee4 : 000178d0 : |                                          | R8
00009ee8 : 204c80bc : |                                          | R9
00009eec : fc175c24 : |                                          | R14: fc175c24 (ASM call to fc160e2c)
         :          : |                                          | fc175c24 = SharedCLibrary +2f994
         :          : |                                          | = print_pagesize +20
         :          : |                                          | fc160e2c = SharedCLibrary +1ab9c
         :          : |                                          | = os_swix +0
00009ef0 : 20002124 : |
00009ef4 : ffffffff : |
00009ef8 : 000178d0 : |
00009efc : 00000000 : |
00009f00 : 00000001 : |
00009f04 : 00000000 : |
00009f08 : 000178d0 : |
00009f0c : 204c80bc : |
00009f10 : 00009f34 : |
00009f14 : 00009f20 : |
00009f18 : 00000001 : |                                          - R4
00009f1c : 00009f50 : |                                          | R11
00009f20 : 00009f2c : |                                          | R12
00009f24 : fc3dd070 : |                                          | R14: fc3dd070
         :          : |                                          | = !Paint +78f8
00009f28 : fc175c10 : |                                          | APCS function: fc175c08
         :          : |                                          | = SharedCLibrary +2f978
         :          : |                                          | = print_pagesize +4
00009f2c : ffffffff : |                                          |
00009f30 : 000178d0 : |                                          |
00009f34 : 00000000 : |                                          |
00009f38 : 00000001 : |                                          |
00009f3c : 00000000 : |                                          |
00009f40 : 000178d0 : |                                          |
00009f44 : 00009f88 : | R11                                      |
00009f48 : 00009f54 : | R12                                      |
00009f4c : fc3de2cc : | R14: fc3de2cc                            |
         :          : | = !Paint +8b54                           |
00009f50 : fc15d7b8 : | APCS function: fc15d7b0                  ? Broken APCS chain?
         :          : | = SharedCLibrary +17520
         :          : | = event_process +4
00009f54 : 0000002f : |
00009f58 : 204c8c58 : |
00009f5c : 204c80c4 : |
00009f60 : 204c80a4 : |
00009f64 : 00009fff : | R4
00009f68 : ffffffff : | R5
00009f6c : 00000000 : | R6
00009f70 : 00000000 : | R7
00009f74 : 204c9f1c : | R8
00009f78 : 204ca14c : | R9
00009f7c : 00009fe4 : | R11
00009f80 : 00009f8c : | R12
00009f84 : fc14a394 : | R14: fc14a394
         :          : | = SharedCLibrary +4104
         :          : | = _main +40c
00009f88 : fc3ddcdc : | APCS function: fc3ddcd4
         :          : | = !Paint +855c
00009f8c : 00610000 : |
00009f90 : ffffffff : |
00009f94 : 00000001 : |
00009f98 : 00000000 : |
00009f9c : 00000000 : |
00009fa0 : 00000000 : |
00009fa4 : 00000007 : |
00009fa8 : 00009fc4 : |
00009fac : 204c9c90 : |
00009fb0 : 204c9ce0 : |
00009fb4 : 2435075c : |
00009fb8 : 00009ff8 : | R0
00009fbc : fc3ddcd0 : | R1
00009fc0 : fc3f4220 : | R4                                       - Return to fc3f4220?
         :          : |                                          | = !Paint +1eaa8
00009fc4 : fc3f457c : | R5
00009fc8 : fc3f457c : | R6
00009fcc : 00000028 : | R7
00009fd0 : 204c9a78 : | R8
00009fd4 : 204c9970 : | R9
00009fd8 : 00009ff4 : | R11
00009fdc : 00009fe8 : | R12
00009fe0 : fc3f4238 : | R14: fc3f4238
         :          : | = !Paint +1eac0
00009fe4 : fc149f94 : | APCS function: fc149f8c
         :          : | = SharedCLibrary +3cfc
         :          : | = _main +4
00009fe8 : 00000000 : | R11
00009fec : 00009ff8 : | R12
00009ff0 : fc1771d4 : | R14: fc1771d4
         :          : | = SharedCLibrary +30f44
         :          : | = _kernel_CallInitProcs +48
00009ff4 : fc3f422c : | APCS function: fc3f4224
         :          : | = !Paint +1eaac
00009ff8 : 69615021 :

One has to revert to !Paint 2.23 to clear this error.

Similarly !Paint 2.23 does not “explode” SpriteExtend on OS4.39

It’s basically being paranoid about the potential for the window furniture to change size on an open window request with the result that the colour indicator dimensions are recalculated and it gets redrawn on every such request.

Uggh. Tool sprite changes were supposed to be announced via message 400CE, but nothing used that. Instead tool changers tend to do a SYS"Wimp_SetMode",MODE, so I’d do it on a mode change and at no other point.

The “transparency” background should not scale with the sprite.

TYPO SORRY I meant to type “shouldn’t scale with the MODE” – the stripes are one pixel high in low colour, two pixels high in 32K and four pixels high in 16M.

What pattern would you prefer?

A checkerboard of two greys is typical, eg Gimp does this:

Where are they being referred to as “old”?

Full info.

And to stress for the avoidance of doubt: Paint has always been terribly unreliable, I’m not pointing fingers for any current instability.

As for CMYK support… <cradles head in hands> I’m fairly sure this is all ROL’s fault. But SpriteExtend’s CMYK support is frankly a comedy of errors. eg, on the left, SpriteExtend putting the “stab” into “having a stab at CMYK”, and on the right, SpriteExtend with a Colour Mapping Function doing what SpriteExtend ought to have done:

(And the one on the right isn’t colorimetrically correct, just not laughably, stupidly, massively wrong)

Oh… RO5 does support CMYK sprites doesn’t it? I haven’t checked.

The “transparency” background should not scale with the sprite.

TYPO SORRY I meant to type “shouldn’t scale with the MODE” – the stripes are one pixel high in low colour, two pixels high in 32K and four pixels high in 16M.

I believe that’s actually a symptom of where Acorn forgot to update ECF patterns to behave sensibly in true-colour modes.

https://www.riscosopen.org/forum/forums/3/topics/2491

Of course they’re still not very useful, but at least they’re sensible.

Oh… RO5 does support CMYK sprites doesn’t it? I haven’t checked.

They’re not supported yet.