Bounty proposal: Paint

I bet that wasn’t very pleasant; ublock filters.

I don’t disagree with some of the things you say. I prefer to refrain from comments that are perhaps, in some way, critical of someone else. If someone chooses to post here, great; if not, that’s also fine.

I bet that wasn’t very pleasant; ublock filters.

There are two icons. One is a sort of pipette and it allows you to choose an element to block. It’s a bit painful to use. Maybe better on a desktop machine?
The other one, if you tap something it’ll open a window with all of the element nesting to get there, so it’s possible to just work backwards until the annoying thing disappears and then save that as a block rule.

I don’t disagree with some of the things you say.

The rest of the things I say…. I’ll help you light the barbecue. ;)

My main point was it was hardly fair or reasonable to throw unrealistic tests at what is essentially an old OS to then poke holes in it for not coping with it.

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

I read a bit of it but like Rick I had issues with the ridiculous pop-ups telling me to create an account. I don’t have ublock on this browser at the moment and trying to fix the web page through the dev console to make it readable is painful. I don’t like social media anyway, so I stopped bothering and closed it.

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…

Yup. When I was doing the zoom code I noticed the geometry all becomes horribly unstable at very high zoom ratios (going from memory here) and decided it was probably a fundamental limitation of using 32-bit integer maths. However, I am quite fond of the fixed point maths and some of the code is quite ingenious. It’s part of the character of RISC OS. The original code also has very little validation of user inputs or sanity checks on function arguments. I’m sure a huge part of that is that it was all written from the philosophy of never doing anything you didn’t need to, in order to save every possible byte and every possible cycle, resulting in the nice performance, responsiveness and compactness of RISC OS that continues even to this day. :)

Nemo presumably knows what a comparatively small community this is and that funds and moreover developer time are extremely limited. Talk of rewriting it all seems a bit pointless to me. The more of it you rewrite, the less you have of what makes our platform interesting, unique and memorable. He’s chosen to stick with it so he must be getting something out of it.

Just my two pence. =)

Let’s keep the thread commentary about Paint rather than about someone else and Paint. For me, it helps to create an inclusive place and forum.

Let’s keep the thread commentary about Paint rather than about someone else and Paint. For me, it helps to create an inclusive place and forum.

I agree the above discussion probably doesn’t belong in the bounty thread. We should be inclusive, yes. I don’t think there’s anything wrong with discussing points raised in criticisms though. Perhaps I mentioned the person a few too many times in my response but I feel I was being rather gentle and not saying anything unfair.

I don’t think there’s anything wrong with discussing points raised

Yup.
Especially given as the Photoshop with the 30,000 pixel limit was Elements 10 from 2011… remind me when the sprite handling code was written? More like 1987? And it could handle twice that? ;)

Question is, though, is that a Paint problem (as you mention fixed point maths and 65K pixels sounds like something that an integer split into two 16 bit halves might fall foul of) or is it something in the underlying OS code?

Perhaps the simplest “fix” is to trap and refuse to edit sprites of that size. After all, is Paint really the right tool for fiddling with a bitmap with any dimension over sixty four thousand pixels?

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

You may find Nitter useful, e.g. https://nitter.net/nemo20000.

https://nitter.net/

I simply must pass on the name to the rest of my family.
Children with a tendency to mispronounce and a family that picks up the quirky¹ result:
“Sots and nitters” are Xmas presents, adult items on the Internet thus causes a name of “Nitter Net”

Now I discover Nitter Net actually exists these days

¹ Hey, what passes for humour round this house had to come from somewhere

It’s good to see more progress on Paint. I’m afraid there are problems with the change to add editable DPI however.

There are two important differences between sprites that use a numbered mode and new format sprites.

Firstly, only sprites that use a numbered mode are allowed to have left-hand wastage. Before changing from a numbered mode you should use SpriteOp 54 to remove left-hand wastage. Currently, if you take a mode 28 sprite with left-hand wastage, change it to 180 dpi, and save it, then Paint will refuse to load the resulting file.

Secondly, for sprites that use a numbered mode the mask has the same BPP as the image, whereas new format sprites have 1 BPP masks. The current version of Paint doesn’t stretch/squash the mask as necessary.

I’ve also noticed that changing DPI disables alpha channels, and it turned a CMYK sprite into a 16M colour sprite.

I’m afraid there are problems with the change to add editable DPI however.

Well spotted. Thanks for your extensive testing Edward.

Row/Column insertion/deletion is broken.

Haven’t needed it for a while, but now… ;)

Okay, test case 1:
Create a sprite that matches the current configuration (do the new sprite and just click on OK ¹ ). Make it fill the screen.
You can click menu over a column, down to Edit→Delete columns and if you drag the pointer, it’ll highlight a section of the sprite (in inverse) and clicking Select will then delete it.
Repeating the action does not appear to do anything.

Test case 2:
As above, but select a different colour depth (such as 256 colours). It doesn’t work at all.
It is worth noting that clicking Select to action the area dragged out for deletion sets the pixel at that point, is the current behaviour somebody being forgotten and replaced with the whatever the selected tool is?

Latest version of Paint in latest ROM. Don’t know how long it’s been like that.

Test case 3:
Doing in by pressing Enter when the box is filled in, and not by clicking Select does work as expected. So it appears to be something acting up in the handling of the second mouse click.

BTW, thank you so much for the PNG export function. I can make images for my blog using RISC OS…
I noticed it wasn’t working, but that’s because the CompressPNG module was renamed PCompMod or something like that. I renamed it, and all is good.

¹ Shouldn’t that say “Create” instead of “OK”?

Row/Column insertion/deletion is broken.

This is actually two separate bugs.

First bug: When editing a low colour depth sprite (e.g. 256 colours), Paint swallows the first “delete columns” mouse click. Not present in RISC OS 5.24, present in RISC OS 5.28 (Oct 2020). I’ll try and narrow this one down further.

Second bug: On the second (and subsequent) attempts to delete columns by mouse click, Paint performs the currently-selected toolbox action (e.g. set colour) instead of deleting the selection. This was first seen in Paint 2.52 (04 Feb 2023) – it was not present in Paint 2.51 (21 Jan 2023).

I’ve narrowed down the first bug (“Paint swallows first mouse click when deleting columns”) to somewhere between Paint 2.25 (17 Aug 2019) and Paint 2.28 (26 Sep 2019). I don’t have any intermediate IOMD ROMs so that’s as close as I can get at the moment.

My records only show 2019-08-20, 2019-08-23, 2019-08-26, 2019-08-31, 2019-09-13,2019-09-22,2019-09-23 as intermediates.

After digging out my archive of Pi ROMs, I can now state that the bug first appeared in Paint 2.27 (22 Sep 2019) – it was not present in Paint 2.26 (25 Aug 2019).

Just to clarify some Twitter-caused misunderstandings above:

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.

Neither of those claims are true. I didn’t complain about either thing.

In fact I was boasting that Paint was coping absolutely fine with an utterly massive sprite with gargantuan proportions that would have been 64GB if it were a typical uncompressed bitimage. But it wasn’t an uncompressed bitimage due to the very clever trickery enabled by my CompressedImage module. It was actually a DrawFile wrapped inside a Sprite.

There are many criticisms that can be made of Paint, so there’s no need to make up new ones.

The biggest problem with Paint is that instead of using the defined SpriteOp to read the presence and size of the Palette, it uses its own heuristic which was always wrong (technically) but is now anachronistically incompatible (especially in the presence of MetaSprite).

That really must be fixed. It became wrong with the release of RO3.

Just to clarify some Twitter-caused misunderstandings

Situation normal then?

There are many criticisms that can be made of Paint

Still waiting for the horribly broken file loading to be reverted back to sanity after being broken somewhere along the way.
https://youtu.be/tJG_3KpRDwo

The biggest problem with Paint […] That really must be fixed.

Rinse and repeat.

broken file loading

<orwell>Imagine a boot stamping on a human face — forever</orwell>