In article <55f2a4ffd1chris@xxxxxxxxxxxxxxxxxxxxx>,
Chris Johnson <chris@xxxxxxxxxxxxxxxxxxxxx> wrote:
In article <55f29736eddave@xxxxxxxxxxxxx>,
Dave Symes <dave@xxxxxxxxxxxxx> wrote:
As noted before going back to version 1.25 which has a much smaller
Max RAM set, the image is displayed without any bother.
I am pretty busy at the moment with other things, so have only just
seen this.
David is correct when pointing out that DPScan converts loaded images
to an RGB raster, akin to a sprite file. Therefore it will need a lot
more memory than the size of the jpeg, which is a compressed format
(and lossy) and may be very compressed. The size of the jpeg file is
not the factor, it is the pixel count of the image.
When you load an image, if the selected tool is either the pointer or
hand then, at the far right of the info window, there is an entry
'Size'. This shows the memory size being used for that image. I have
just loaded a 3000x2000 jpeg and the size in memory is 18M.
The next thing is the apparent difference between 1.25 and 1.27
(David's last release was 1.26, by the way). The code to load and
display a jpeg has not been changed by me. The only difference in
jpeg handling is that David links to version 6 (I think) of the IJPG
library, and I am using the later version 9.
Real RISC OS hardware appears ok. Your SARPC is fine. Later hardware
running RISC OS 5 is fine. I use it all the time without problem. I
have even managed to view and manipulate an image 18000x18000 (a NASA
composite high res image of Saturn and its rings).
The problem seems to be on RPCEmu. Can you load any jpegs at all? I
have no experience with that and have no idea how it manages memory.
One thing you could do is up the wimp slot and try again. DPScan
manages its own memory, claiming it from (increasing) the wimp slot or
from a dynamic area on the fly, depending on the OS in use.
