Bounty proposal: Paint

Now, this looks to me (just a cursory glance) to be the menu block for the stand-alone “Rename” menu object.

That sounds very plausible.

The really big question here is… how/why the hell is the Filer trying to access Paint’s menu?

That might be a question for Andy Vawer as it seems to be going on due to code in CnPCaret.

My current best guess (and it really is a guess) is that when wimp_poll() is called (from Paint or the Filer, not sure which), the SharedCLibrary or WindowManager is deciding that it needs to unset the caret from its current owner (the Paint Rename menu) (Why, I don’t know. Presumably because of your press of Enter or the menu being destroyed). Unsetting the caret seems to trigger a redraw of the menu that previously had the caret. I guess if that hadn’t bombed out then the caret might’ve been passed on to the Filer.

I don’t think it’s the Filer itself trying to access Paint’s menu. I think it’s the WIMP’s clipboard / caret handling housekeeping stuff going on during a WIMP poll. Presumably the Filer was the most recently active application. Again these are really guesses, though. * shrugs *

It’s an oddity that seems to relate to temporary caret placements. I don’t know yet if it’s because there is an internal attempt to redraw something that’s no longer valid (eg window closed/deleted or task killed) or due to the appropriate task not being paged in at the right time. I have found a way of reliably (!) breaking it but haven’t got to the bottom of it yet, apologies. But it is very much on the radar as when it kicks off it is certainly a major show-stopper! Filer gets nobbled because of bad luck (just so happened to be the task running at the time) and not having any application memory; I suspect if an application task were paged in there would be fewer fireworks.

It’s an oddity that seems to relate to temporary caret placements. I don’t know yet if it’s because there is an internal attempt to redraw something that’s no longer valid (eg window closed/deleted or task killed) or due to the appropriate task not being paged in at the right time.

The problem that I saw seemed more obvious: what I concluded was happening (in WinEd and CashBook) was as follows:

1. A document window is open and holds the caret. The user closes it.
2. Because the document is unsaved, the application initiates an “are you sure” process ending with a transient SaveAs dialogue open on the screen. As it’s transient, the Wimp moves the caret from the document window into the writeable icon of the transient dialogue.
3. The user saves the document, resulting in the transient SaveAs dialogue closing.
4. The application now discards the document, and deletes its window. Control then passes back to the Wimp.
5. Because of 3, the Wimp now needs to restore the caret to where it was before the transient dialogue opened. Unfortunately it doesn’t seem to check that the window still exists, and since it was deleted in 4… Boom.

Since transient dialogues are just menus, could a similar effect be occurring with a menu — especially if there’s a writeable field in there?

I wonder whether this is related to something I see infrequently, mostly, but not always, involving Pipedream. The message is something like “window with caret not found”, and seems to be triggered when Pipedream has some of its windows iconised. However I’ve seen the message in other situations too.

Easy to reproduce with PipeDream 4.58:
Type into a new document.
Iconise window to Pinboard.
Press a key → Error “Input focus window not found”.
Why is WindowManager delivering key events to that window?

Can’t say that I’ve seen this before as I never iconise windows! Error is not generated when running on RISC OS 3.71.

Just a little update for your amusement.

I’m still using Paint 2.42 (I’ll need to update, I noticed the PNG addition, though shame it doesn’t support transparency (yet?)) and RISC OS 5.29 of 15th July as it doesn’t seem your proposed Wimp update has made it through to the mainstream build yet.

So I’m renaming a sprite, and suddenly “kaboom”, the Filer dies. Only this time, it also takes out Paint… whilst leaving the entire Paint menu structure on the screen (and the Rename writeable icon utterly empty).

Placing the mouse over that menu structure causes the Wimp to explode in lots of gooey gloopy pieces. It’s limping along now with half the tasks that used to be running, no Switcher, and the scroll wheel non-functional. Time to attempt to shut down (though I rather imagine it’ll start throwing exceptions) and prod the Reset button.

Guys – given that the nightlies are supposed to be for testing, can we please try that one-line fix to see if it breaks anything, because the current situation is kind of broken if attempting to rename something in one of the built-in applications brings the machine down.

If it might have helped there was a test Pi ROM here which contains the one line addition, CLRV wrapped in a CnP switch, in Wimp.s.Wimp05. The test build is now withdrawn.

Possibly related to CnP, possibly not… But I have noticed that with the very recent (test #5312) version of NetSurf and RISC OS 5.29 that’s about a month old, I cannot drag a URL to Zap (or another window) by clicking the URL bar and dragging it… and there’s no functional cut and paste behaviour for the URL.

Is this a “work in progress”?

The bugs are never ending. I’ve somehow only just noticed that translucent plotting (used for brush opacity) isn’t actually working right on the 256 greyscale sprites either. As an example, choose colour 255, pure white, to paint onto a white sprite but with the opacity slider turned down to, say, 99% opacity, and the brush stroke comes out in a light grey! Blending white with white should always be white, no matter the translucency value! Other colour values are similarly pathological.

I’ll try and finish a simple repro program for this when I’m feeling a bit less shattered.

The bugs are never ending.

Allow me to toss another on the pile. ;-)

Deleting columns or rows. If you zoom in a bit and then click at the extremities of the sprite (very top, very left, etc) and then use the mouse move method to determine how many columns/rows to get rid of, it will be highlighted correctly, but clicking to do the delete will result in nothing happening.
To make it work, you need to begin pretty much by the second column/row.

An off by one error?

[don’t expect you to fix this as it’s not part of the bounty, just thought I’d mention it as Paint has quite a number of lurking bugs!]

Allow me to toss another on the pile. ;-)

Aww thanks that’s so sweet of you Rick!

[don’t expect you to fix this as it’s not part of the bounty, just thought I’d mention it as Paint has quite a number of lurking bugs!]

From what I’ve seen the insert / delete columns / rows tool is horribly complicated so probably best left well alone at the moment. For what it’s worth, I tried clicking as close as I could to the left edge of the sprite when zoomed in and it showed me 1 column to delete on the little dialogue box and it did delete one column when I clicked again, so the issue isn’t straightforward to reproduce.

Ah I’ve made it happen now. I had to switch to a really low resolution to get the mouse pointer right to the edge. It was quite hard to do, though.

Re the crashing problem; have you tried running Tom Hughes’ !WimpMon to see what poll codes are being chucked about?

so the issue isn’t straightforward to reproduce.

My display is 1280×1024.
Sprites are usually zoomed to something like 8x or 10x to allow pixels to be easily changed without mucking up adjacent ones by accident.
Clicking then dragging to select multiple columns or rows usually fails the first time for me as I click where is logical, not where Paint likes.

is horribly complicated so probably best left well alone

Oh, yes. I’ve looked at the source.

Out of interest, I also looked at the source in order to see how Paint exports a single sprite, given that SpriteOp doesn’t have a way of doing that.
Uh hu. Okay. ;-)

CTRL + scrollwheel zoom now in Paint 2.44 is very useful and works well on both the RPi4B and RPi400. The slight downside was that the Titanium was having none of it.

It took a while, but ‘Line multiple’ needs to be ticked in Mouse Configuration.

HTH.

As requested some time ago you can also now zoom in coarse steps by holding down Shift as well as Ctrl when you drag the resize button diagonally (it’s a little flickery at the moment but I’m looking into that).

The slight downside was that the Titanium was having none of it.

It took a while, but ‘Line multiple’ needs to be ticked in Mouse Configuration.

David that sounds like it might be the fix we had to put in for the USB driver module. For a long time it was generating multiple scroll requests when the scroll wheel was moved one step, What version of USBDriver are you running? If it’s older than 1.30, Paint would be enabling the fix. That said, I don’t know what ‘Line multiple’ does.

What version of USBDriver are you running? If it’s older than 1.30, Paint would be enabling the fix.

Up to date here.

*FX0
RISC OS 5.29 (31 Aug 2021)
*help usbdriver
==> Help on keyword USBDriver
Module is: USBDriver       1.31 (19 Jun 2021)

That said, I don’t know what ‘Line multiple’ does.

And I’ve forgotten. (Or never really knew!)

But I know who does.

From your link:

Part of the problem is that there are three different ways of scrolling windows (“open window” wimp messages, “scroll” wimp messages, and “extended scroll” wimp messages), and there’s not much consistency with how programs react to them.

Possibly Paint could be updated to respond to all three to negate the need for ‘Line multiple’. I’ll have to see if I can find a suitable wheel mouse to plug into my Pi as I use a track pad.

The soft brushes work great in a 16M sprite with simple mask.

But if you make a 256 sprite with simple mask, and the display is set to 16M colours, the soft edges appear as random colours rather than greys. To make it work you have to change the display to 256 colours.

Also if you try and use a soft brush on a 256 colour sprite with no mask at all the screen flashses and it wipes the whole sprite (seen in sprite file window – sprite window itself not updated).

Thanks for the feedback.

But if you make a 256 sprite with simple mask, and the display is set to 16M colours, the soft edges appear as random colours rather than greys. To make it work you have to change the display to 256 colours.

I think that’s a result of this bug. If you give the 256 colour sprite a palette, the colours should come out right. This issue may be fixed in a future version of ColourTrans. We’ve also been discussing the possibility of a workaround in Paint (it would use a default palette while the sprite is being edited).

Also if you try and use a soft brush on a 256 colour sprite with no mask at all the screen flashses and it wipes the whole sprite (seen in sprite file window – sprite window itself not updated).

Ah yeah, mea culpa, I think. If that’s what I think it is, it should only be a one line fix.

One known issue is that painting with the brush tool in the transparent colour doesn’t work on alpha channel sprites at the moment. This is a limitation of the OS.

The tint looks promising. (By the way at the moment it shows an EORed rectangle before clicking – does it make sense to somehow show the brush so it works more like the text tool?).

Using 16M, say you make a brush that’s a big black ‘A’ with the background white. Then select fore-colour navy blue and paint with it. The background comes out light blue, and the A comes out dark blue (neither the selected navy). At first I vaguely expected for it to act like a mask i.e. the black comes out navy blue, and the white comes out white. I guess that would’ve corresponded to the grey shade of the brush being interpreted as saturation.

So if you want to make a tinted brush that gives exactly the fore-colour selected when you paint … what shade of grey does the brush need to be?

Dragging the sprite into the brush pane is nifty :-)

(By the way at the moment it shows an EORed rectangle before clicking – does it make sense to somehow show the brush so it works more like the text tool?)

The use of EOR is for speed. It makes a copy of the brush sprite, converted to an on-off mask, for the mouse pointer. It won’t always be a rectangle. Any pixel that isn’t fully transparent will be solid on the mouse pointer sprite.

Using 16M, say you make a brush that’s a big black ‘A’ with the background white. Then select fore-colour navy blue and paint with it. The background comes out light blue, and the A comes out dark blue (neither the selected navy). At first I vaguely expected for it to act like a mask i.e. the black comes out navy blue, and the white comes out white. I guess that would’ve corresponded to the grey shade of the brush being interpreted as saturation.

Tint mode just averages the RGB values of the selected foreground colour and the colour of each pixel on the brush sprite, i.e. (foreground_colour * 0.5) + (brush_sprite_pixel_colour * 0.5).

So if you want to make a tinted brush that gives exactly the fore-colour selected when you paint … what shade of grey does the brush need to be?

With the current Tint algorithm, the only way to get exactly a specific foreground colour when you paint is for the brush sprite to actually be that colour.

I can’t really think of a good algorithm to achieve the behaviour you’re describing. We could have a brush mode that just alters the hue based on the selected colour but then the saturation and lightness of the brush sprite pixels would have to exactly match the selected colour to get that exact colour.

Dragging the sprite into the brush pane is nifty :-)

Thanks!

@andy, see here and here for observations and historical insights on Paint.

If you are sensitive to feedback, don’t click the links! ;)

Hmmm, have to fiddle with UBlock’s filters again to stop Twitter throwing up a “sign in or sign up” after three tweets.

As for the content, funny how it’s so much easier to complain about how things are broken rather than do anything useful to help.

I mean, he’s complaining that a 64GB sprite is showing up as 196 bytes. Or that it’s acting up with a sprite with a dimension of 65,536. Hardly typical behaviour in the days when that stuff was written. As he noted, Photoshop used to have a smaller boundary…