JSBeeb corruption in various browsers

[Matt Godbolt]

It seems Tricky noticed this corruption last October.
https://github.com/mattgodbolt/jsbeeb/issues/309

Lee.

Interesting: I couldn't repro on Chrome 88 on Linux, so although that initially looked like an emulation problem it does seem to be GL related.

BTW you can add the `glEnabled=false` to the URL to try things with GL disabled explicitly.

[Matt Godbolt]

Unless it's emulating a Beeb with knackered DRAMs?

LOL

[jimmy]

... I did this and the corruption has almost gone - but now I just get a white border (single pixel) around the screen which flickers too much to be comfortable with. The flickering also affects every game so it's not usable.

Not that it's a long-term solution, but does the flickering stop if you slightly resize the whole Firefox window?

Yes . Further checks seem to show that when I set the about:config option, I only see the flickering when I've maximized the browser window. If I return the window to it's normal size then the flickering goes away, but I do see some image corruption on the bottom line.
I've tried changing my Ubuntu machine to use NVidia's closed-source driver. It made no difference.
Firefox 85 on Windows with NVidia graphics works just fine.

[Matt Godbolt]

So very odd! We're not doing anything particularly "clever" in the renderer. If you go to another site that uses shaders do you get issues? e.g. https://www.shadertoy.com/view/WtSBzh ?

[Rich Talbot-Watkins]

This is the same thing which comes back again and again with jsbeeb on Windows. It happens for me every now and then, and normally force-upgrading Google Chrome fixes it.

I think it's a bug in jsbeeb though. For example, the sort of thing which it might be is not clearing all of the border from one frame to the next. We can't assume that a dynamic texture will always come from the same place in VRAM, and may sometimes perhaps be presented to WebGL uninitialized, instead of containing the previous texture data. Something like that anyway...

[Matt Godbolt]

Sounds entirely plausible Rich! Something something texture reuse and driver (rightly) can give us a new whole render target or something...

I'll note that in the bug! (I just resurrected jsbeeb's CI/CD setup after a run-in with travis...so I can do updates again!)

[leenew]

This is the same thing which comes back again and again with jsbeeb on Windows. It happens for me every now and then, and normally force-upgrading Google Chrome fixes it.

I think it's a bug in jsbeeb though. For example, the sort of thing which it might be is not clearing all of the border from one frame to the next. We can't assume that a dynamic texture will always come from the same place in VRAM, and may sometimes perhaps be presented to WebGL uninitialized, instead of containing the previous texture data. Something like that anyway...

Is it just me? or is this problem getting worse?
This is Farmer 'Jo' a completely BASIC program doing nothing fancy, and it has corruption in the actual screen area, not the border!

This is in EDGE on WIN64bit.

Lee.

[Matt Godbolt]

Can you post a link to that BASIC program or other reproduction? I'd love to see if it happens reproducibly. You're right, it doesn't appear to be related to the other border issues, which makes me wonder if it's a more "normal" emulation problem.

[Deleted User 9295]

This is in EDGE on WIN64bit.

The version here runs fine for me, with no corruption, also using Edge in Windows 10 (64-bits) .

[leenew]

Very strange Richard as that is the version I am using!
I can't seem to pin this down but I am seeing corruption in different games sometimes in the border and sometimes on the play area across different browsers and on 2 devices. One is a windows 64 bit PC (quite old) and one is a Windows 32 bit laptop (quite old).

Lee.

[Matt Godbolt]

Thanks both. I'll assume they're related until we know otherwise.

[lovebug]

i just played magic eel on windows 7 64 bit firefox 88.0 no issues, screen is ok

--- edit ---- laptop with i3 and intel hd graphics on the cpu chip

[leenew]

UPDATE:
I AM SEEING CORRUPTION IN VARIOUS BROWSERS WITH VARIOUS GAMES.
COULD ANYONE SEEING SCREEN CORRUPTION IN JSBEEB PLEASE POST THE DETAILS.

Thanks.

[Rich Talbot-Watkins]

99% sure it's an emulator bug.

jsbeeb only renders to the texture when display is enabled (code) so it's assuming that what's already there is black (e.g. in the border, or gaps between rows in MODE 3/6).

Maybe something wrong with the frameskip logic (code) where it can skip a frame without clearing the buffer, and then paints the following frame over the current?

WebGL doesn't seem to have ways of being more specific about the access type of a texture resource (read-only, dynamic write, etc) so I don't see that it's a problem with the use of texSubImage2D in Canvas (code), but it feels like there's some sort of undefined behaviour being invoked somewhere which triggers an edge condition on some drivers.

[Rich Talbot-Watkins]

When you're seeing this kind of corruption, it'd be interesting to know if forcing interlace off (*TV0,1) causes stuff to settle down on mode changes. Interlace mode relies on alternate lines from the previous frame not being cleared, whereas non-interlace should do a fast full buffer clear.

[Deleted User 9295]

Very strange Richard as that is the version I am using!

This seems likely to be down to differences in graphics hardware/drivers. You might want download GPU-Z; for what it's worth this is what it tells me:

[Rich Talbot-Watkins]

This seems likely to be down to differences in graphics hardware/drivers.

Agreed, but, ultimately, the problem is bound to be a buggy emulator rather than a really serious driver bug I suspect. I've had this happen on occasion, on cutting edge graphics hardware, and the problem has normally been "fixed" by upgrading the web browser. Not that I think it's a fault of the browser either; just that doing so resets some kind of driver state which jsbeeb is putting it into.

I don't have the time right now (or even the masochistic tendencies) to debug Javascript, but am happy to keep flinging out unsubstantiated theories!!

[Matt Godbolt]

I don't have the time right now (or even the masochistic tendencies) to debug Javascript, but am happy to keep flinging out unsubstantiated theories!!

100% Thanks for the insights Rich!

[scarybeasts]

UPDATE:
I AM SEEING CORRUPTION IN VARIOUS BROWSERS WITH VARIOUS GAMES.
COULD ANYONE SEEING SCREEN CORRUPTION IN JSBEEB PLEASE POST THE DETAILS.

Thanks.

Does
https://bbc.godbolt.org/?glEnabled=0
help at all?


Cheers
Chris

[tricky]

It didn't a few (6?) months ago when I last tried setting it.

[leenew]

I told you it was old!

[leenew]

UPDATE:
I AM SEEING CORRUPTION IN VARIOUS BROWSERS WITH VARIOUS GAMES.
COULD ANYONE SEEING SCREEN CORRUPTION IN JSBEEB PLEASE POST THE DETAILS.

Thanks.

Does
https://bbc.godbolt.org/?glEnabled=0
help at all?


Cheers
Chris

Loading the Farmer Jo disc from here made no difference...

Lee.

[leenew]

When you're seeing this kind of corruption, it'd be interesting to know if forcing interlace off (*TV0,1) causes stuff to settle down on mode changes. Interlace mode relies on alternate lines from the previous frame not being cleared, whereas non-interlace should do a fast full buffer clear.

If I do a *TV0,1
then a MODE 7
then a *EXEC !BOOT on the FarmerJo image, I get no corruption in the play area, but still get corruption in the border...

Lee.

[BeebMaster]

Do you think we should agree on some simple test code to draw things on the screen and then compare notes? It might be a bit more scientific than "this game does this sometimes..." type approach.

[Deleted User 9295]

I told you it was old!

AMD's website seems to suggest that using an ATI Radeon HD 2600 XT with Windows 10 is not really supported. Although there is a driver available from Windows Update (it's the one you are using) they recommend either downgrading your version of Windows (!) or upgrading to a later graphics card, neither of which is probably a realistic option for you.

So although that probably isn't the cause of the display glitches you are seeing, it remains a possibility. It would be interesting to know if anybody is seeing the problem when using an officially-supported GPU with up-to-date drivers.

[tricky]

I'm on Windows 7, but I did have an ATI last time I had the corruption, but with the latest win7 driver.

[lurkio]

More reports of JSBeeb performance issues:

i too have issues with jsbeeb, my laptop is a 3rd generation i3 with no external gpu, it just has the intel hd graphics on the cpu chip ... ive tried my main browser firefox and also chrome but i also have issues with jsbeeb on any bbc game ... very sluggish with broken choppy sound. never works for me ... i use beebem app on my laptop and everything runs perfectly smooth

viewtopic.php?p=329862#p329862

[Deleted User 9295]

More reports of JSBeeb performance issues:

To be fair, one shouldn't expect the performance of a JavaScript program running in a browser to be comparable with a program running natively on the host processor; that's just the inevitable overhead of the browser/JS environment rather than being indicative of a JSBeeb "performance issue". Even running Web Assembly code in a browser, which is faster than JavaScript, I still see more than a 10-fold reduction in speed compared with the same code running on the host CPU.

[Matt Godbolt]

Thanks Richard - you're right in general! That said: jsbeeb was developed on a then-10-year old laptop and it ran passably fast on that after filing a few issues with both Chrome and Firefox. I suspect there's some regression in Firefox. I can try and take a look sometime.

[Deleted User 9295]

I suspect there's some regression in Firefox.

Yes, regressions are really annoying, especially with something like JSBeeb or my in-browser edition of BBCSDL. Somebody might be using it to deploy a program they have written, only to discover that it gets slower for no apparent reason, and completely out of their control.