Two Graphics Bugs

I seem to have acquired two bugs in the same minute on the RPi3, which may or may not be related, on updating to the current ROM, 30Oct17.

Paint’s Sprite file window is over-written by garbage left over as another window is dragged over it or as it is drag resized. This appears to be associated with Paint 2.22.

JPEGs are displayed on a very blocky manner as if a very low resolution image is being expanded. This can be as a backdrop or with PrivatEye or SwiftJPEG. The ROM of 11Sep17 is good.

Oddly, or otherwise, none of this happens on the Titanium with the same date ROM, 30Oct17.

http://pittdj.co.uk/rool/rpi3.png

JPEGs are displayed on a very blocky manner as if a very low resolution image is being expanded. This can be as a backdrop or with PrivatEye or SwiftJPEG. The ROM of 11Sep17 is good.

SpriteExtend 1.80 is the culprit. Purloin 1.79 from an earlier ROM and softload that over the 30Oct17 ROM and JPEGs display properly on the RPi3.

SpriteExtend 1.80 is the culprit

I think that’s probably just coincidence, since as you mention the same image is OK on Titanium, but not on a Pi 3. I’ve just tried out your test (using the Abstract-fs/jpg image off the Pi) and have a hunch what the problem is – hopefully some head scratching this evening will reveal more, or draw blood.

hopefully some head scratching this evening

This was successful, today’s RPi ROM 01Nov17 resolved both issues.

Many thanks.

Duplicate post deleted. A stalled forum event!

That’s odd, since nothing’s changed in CVS. But there is definitely a new set of ROM builds available, which would normally only happen if there’s been a change in CVS.

It is a real build with a real change. Sprow has sorted something.

MLS?

Yes, a change to the DDE version used by the build machine would trigger a new build (and wouldn’t show up in CVS). But I’m waiting to see what Sprow says before I jump to too many conclusions!

It is a compiler issue.

I had to revert to DDE27 this morning to build a working ROM which fixed both bugs, which were related as it turns out.

I’m waiting to see what Sprow says before I jump to too many conclusions!

I disassembled the SpriteExtend from Titanium (working, built as -cpu 7) and Pi (not working, built as -cpu 6) and diff’d the two. There appeared to be a very specific case where the optimiser had chucked away a move if an MLS happened right at the end of a function. In this case it was in jdhuff.c and in the ARMv6 case ended with SUB r0,rN,rN, which is mostly 0.

If today’s ROM looked good then that means some late night candle burning got a fixed compiler on the auto builder. Nice.

There appeared to be a very specific case where the optimiser had chucked away a move if an MLS happened right at the end of a function

Does that mean there’s a bug in DDE28? Or is there a bespoke compiler for the ROM?

I think it’s the same compiler built for x86 (Linux?). Shame it isn’t available to us…

Anyway, David Pitt’s comment implies a compiler issue.

Does that mean there’s a bug in DDE28?

Yes. ROOL are on the case. A fixed version has been applied to ROOL’s autobuilder, whatever that is.

I think it’s the same compiler built for x86 (Linux?).

I think, from memories of previous comments from Those Who Should Know, that it’s exactly the same DDE that we use, running on RISC OS, within an RPCEmu environment, on a Linux server.

Shame it isn’t available to us…

It is…

There’s a new version of CC in existence (5.75) which I presume will be released to the public in due course.

Steve:

running on RISC OS, within an RPCEmu environment, on a Linux server.

Oh… Okay. I kind of imagined it had been compiled to run native on the server and was cross-compiling…

Chris: I imagine a DDE update will be around soon, the modifications will need to be tested (and how better than building the OS a few times for different architectures?). ;-)

There’s a new version of CC in existence (5.75) which I presume will be released to the public in due course.

Indeed, the new version arrived in my inbox this morning.

Oh… Okay. I kind of imagined it had been compiled to run native on the server and was cross-compiling…

That’s not really feasible at the moment. Although the compiler does/did support cross-compilation, there are too many other bits of the build which currently only work under RISC OS (some quicker/easier to fix than others).