Page 1 of 1
Gemview DSP usage, does anyone know?
Posted: 04 Aug 2025 18:41
by pixelpusher
I was recently dusting off my Falcon, peeking into some DSP programming. When looking at Gemview (of cause with installed JPEGD.PRG - v.094 - in the AUTO folder) I wasn't sure, if Gemview uses it at all (there's no visible message about when it's used or not - at least in my Gemview v3.15).
To me it seems like Gemview might only be using the DSP in the "True color" mode, but not in any of the lower color modes. Has anybody more insight or other experiences with it?
Re: Gemview DSP usage, does anyone know?
Posted: 04 Aug 2025 20:00
by dml
pixelpusher wrote: 04 Aug 2025 18:41
To me it seems like Gemview might only be using the DSP in the "True color" mode, but not in any of the lower color modes. Has anybody more insight or other experiences with it?
I'm not sure - but you could find out by either timing it or using Hatari to monitor DSP activity with the profile feature.
I expect if it is using the DSP JPEG driver at all, it will be using it in every mode, but will spend additional time down-converting the image to indexed colour afterwards in e.g. 16/256c modes.
The only benefit I could see *not* to operate that way would be if the down-conversion/quantization/dithering happens to be better in an alternative JPEG library than what can be done by GEMVIEW itself after loading the image.
Re: Gemview DSP usage, does anyone know?
Posted: 04 Aug 2025 21:06
by pixelpusher
dml wrote: 04 Aug 2025 20:00
pixelpusher wrote: 04 Aug 2025 18:41
To me it seems like Gemview might only be using the DSP in the "True color" mode, but not in any of the lower color modes. Has anybody more insight or other experiences with it?
I'm not sure - but you could find out by either timing it or using Hatari to monitor DSP activity with the profile feature.
I expect if it is using the DSP JPEG driver at all, it will be using it in every mode, but will spend additional time down-converting the image to indexed colour afterwards in e.g. 16/256c modes.
The only benefit I could see *not* to operate that way would be if the down-conversion/quantization/dithering happens to be better in an alternative JPEG library than what can be done by GEMVIEW itself after loading the image.
Based on the timing, which seems to be nearly identical with/without JPEGD.PRG in modes below 32k colors, I'd assume its not using the DSP; HATARI should help to confirm that thesis... (good idea!).