[Rpcemu] Full screen display

I'm running RPCEmu under Linux Mint 20.1 on a decade-old
Samsung 17" laptop with a 1600 x 900 screen driven by an
Nvidia graphics card. It has an i3 CPU, 8 GB of RAM and a
480 GB SSD. It runs very well indeed thank you very much,
except...

I can't get it to run properly in full-screen mode.

Without selecting full-screen, I have a working 1600 x 900
mode in 16 million colours and with a 60 Hz refresh. Using
<alt>click-drag, I can move the window to cover the whole
screen. The panel at the bottom of the screen is set to
auto-hide.

After a fresh boot, with the RPCEmu window in its default
position, selecting full-screen mode from the drop-down
menu results in the window losing its title bar and
becoming immovable. This happened with the default video
driver even before I invoked the Nvidia 340 driver.

Setting a mode with a lesser height than that of the
display *does* allow full-screen mode to be used.

You might ask why I need to enter full-screen mode if I can
make it look as if that's how it is just by moving the
default window to cover the screen. Well, I don't know if
this is known/expected behaviour or if there is a bug
(feature?) with RPCEmu.

I can certainly live with this situation and only raise it
in case there is a remedy of which I'm unaware or, indeed,
if a remedy is at all possible.

John

--
John McCartney
j.mccartney@blueyonder.co.uk

_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [gccsdk] GCC on RISC OS hanging

Lee Noar wrote on  30 March 2021 14:23

> On 29/03/2021 18:57, alan buckley wrote:
> > I�ve been trying to build my packit code on RISC OS 5.24 on RPCEmu. It
> > just seems to hang. Occasionally the screen get�s corrupted or an error
> > box (that I can�t see properly or read) appears. I�ve no idea what is
> > causing this and I�ve not been able to eliminate anything to narrow it down.
> >
> > Smaller programs seem to compile OK.
> >
> > Any suggestion on what may be going wrong?

> Is this in a taskwindow? If you attempt it from a single tasking command
> line, does that give you a more useful error?

Still hangs (on my first attempt it crashed RPCEmu). On the second attempt

It hung but reported a missing library (which I know had been seen).

> Are you using make, perhaps for your project, but calling GCC directly
> for smaller programs; could it be make at fault rather than GCC?

 

I've always used make for all the programs. You could be correct about

it being make instead of GCC though as I put just the g++ link command

in an Obey file and the ran OK.

Lee.

Re: libnsgif and memory bombs

That's great, thanks Michael. I'll remove my patch and update from your repo.

On Mon, 5 Apr 2021 at 14:51, Michael Drake
<michael.drake@codethink.co.uk> wrote:
>
> Hi John,
>
> Thanks for the patch. It is an improvement and I've applied it.
> I'm currently considering moving the call to gif_initialise_sprite
> into gif_decode_frame so that the bitmap area is always created
> when a client calls gif_decode_frame. At the moment it will only
> happen for the first frame that is to be displayed, which is a
> change in behavior.
>
> I've fixed decode_gif.c to consult the display flag.
>
> By the way, your patch had tabs for indent, but that file
> (inexplicably) uses spaces. I changed the patch to use
> spaces to match but I plan to convert the whole file to
> tabs soon.
>
> Best regards,
> Michael
>
>
> On 03/04/2021 12:33, jcupitt@gmail.com wrote:
> > Here's a better version of the patch:
> >
> > https://github.com/libvips/libvips/blob/master/libvips/foreign/libnsgif/patches/delay-alloc.patch
> >
> > (removes a stray create_bitmap call)
> >
> >
> > On Fri, 2 Apr 2021 at 11:58, <jcupitt@gmail.com> wrote:
> >>
> >> Hi all,
> >>
> >> I had a thought regarding memory allocation in libnsgif.
> >>
> >> At the moment, calling `gif_initialise()` will parse the GIF file and
> >> allocate memory for rendering. You then call gif_decode_frame() to
> >> decompress and render each frame of the animation.
> >>
> >> However, this means just opening the GIF can trigger very large memory
> >> allocations, with no chance for the caller to intervene, except by
> >> putting a hard pixel limit into the bitmap_create() callback. For
> >> example, a 20 byte GIF can cause a 17gb malloc.
> >>
> >> How about delaying the allocation of the bitmap until the first call
> >> to gif_decode_frame()? This would allow the caller to check the
> >> detected width and height and apply some kind of size policy before
> >> allowing rendering to occur.
> >>
> >> Here's a possible patch that does this. It's very simple and does not
> >> affect the API, just the memory behaviour (I think):
> >>
> >> https://github.com/libvips/libvips/commit/9bdf5e8cda3e0c63584984282b1e36d97c50bb1a
> >>
> >> John
> > _______________________________________________
> > netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
> > To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org
> >
>
> --
> Michael Drake https://www.codethink.co.uk/
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

Re: libnsgif and memory bombs

Hi John,

Thanks for the patch. It is an improvement and I've applied it.
I'm currently considering moving the call to gif_initialise_sprite
into gif_decode_frame so that the bitmap area is always created
when a client calls gif_decode_frame. At the moment it will only
happen for the first frame that is to be displayed, which is a
change in behavior.

I've fixed decode_gif.c to consult the display flag.

By the way, your patch had tabs for indent, but that file
(inexplicably) uses spaces. I changed the patch to use
spaces to match but I plan to convert the whole file to
tabs soon.

Best regards,
Michael


On 03/04/2021 12:33, jcupitt@gmail.com wrote:
> Here's a better version of the patch:
>
> https://github.com/libvips/libvips/blob/master/libvips/foreign/libnsgif/patches/delay-alloc.patch
>
> (removes a stray create_bitmap call)
>
>
> On Fri, 2 Apr 2021 at 11:58, <jcupitt@gmail.com> wrote:
>>
>> Hi all,
>>
>> I had a thought regarding memory allocation in libnsgif.
>>
>> At the moment, calling `gif_initialise()` will parse the GIF file and
>> allocate memory for rendering. You then call gif_decode_frame() to
>> decompress and render each frame of the animation.
>>
>> However, this means just opening the GIF can trigger very large memory
>> allocations, with no chance for the caller to intervene, except by
>> putting a hard pixel limit into the bitmap_create() callback. For
>> example, a 20 byte GIF can cause a 17gb malloc.
>>
>> How about delaying the allocation of the bitmap until the first call
>> to gif_decode_frame()? This would allow the caller to check the
>> detected width and height and apply some kind of size policy before
>> allowing rendering to occur.
>>
>> Here's a possible patch that does this. It's very simple and does not
>> affect the API, just the memory behaviour (I think):
>>
>> https://github.com/libvips/libvips/commit/9bdf5e8cda3e0c63584984282b1e36d97c50bb1a
>>
>> John
> _______________________________________________
> netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
> To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org
>

--
Michael Drake https://www.codethink.co.uk/
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

Re: libnsgif and memory bombs

Thanks John,

I'll have a look at it soon.

Best regards,
Michael

On 03/04/2021 12:33, jcupitt@gmail.com wrote:
> Here's a better version of the patch:
>
> https://github.com/libvips/libvips/blob/master/libvips/foreign/libnsgif/patches/delay-alloc.patch
>
> (removes a stray create_bitmap call)
>
>
> On Fri, 2 Apr 2021 at 11:58, <jcupitt@gmail.com> wrote:
>>
>> Hi all,
>>
>> I had a thought regarding memory allocation in libnsgif.
>>
>> At the moment, calling `gif_initialise()` will parse the GIF file and
>> allocate memory for rendering. You then call gif_decode_frame() to
>> decompress and render each frame of the animation.
>>
>> However, this means just opening the GIF can trigger very large memory
>> allocations, with no chance for the caller to intervene, except by
>> putting a hard pixel limit into the bitmap_create() callback. For
>> example, a 20 byte GIF can cause a 17gb malloc.
>>
>> How about delaying the allocation of the bitmap until the first call
>> to gif_decode_frame()? This would allow the caller to check the
>> detected width and height and apply some kind of size policy before
>> allowing rendering to occur.
>>
>> Here's a possible patch that does this. It's very simple and does not
>> affect the API, just the memory behaviour (I think):
>>
>> https://github.com/libvips/libvips/commit/9bdf5e8cda3e0c63584984282b1e36d97c50bb1a
>>
>> John
> _______________________________________________
> netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
> To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org
>

--
Michael Drake https://www.codethink.co.uk/
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

Re: libnsgif and memory bombs

Here's a better version of the patch:

https://github.com/libvips/libvips/blob/master/libvips/foreign/libnsgif/patches/delay-alloc.patch

(removes a stray create_bitmap call)


On Fri, 2 Apr 2021 at 11:58, <jcupitt@gmail.com> wrote:
>
> Hi all,
>
> I had a thought regarding memory allocation in libnsgif.
>
> At the moment, calling `gif_initialise()` will parse the GIF file and
> allocate memory for rendering. You then call gif_decode_frame() to
> decompress and render each frame of the animation.
>
> However, this means just opening the GIF can trigger very large memory
> allocations, with no chance for the caller to intervene, except by
> putting a hard pixel limit into the bitmap_create() callback. For
> example, a 20 byte GIF can cause a 17gb malloc.
>
> How about delaying the allocation of the bitmap until the first call
> to gif_decode_frame()? This would allow the caller to check the
> detected width and height and apply some kind of size policy before
> allowing rendering to occur.
>
> Here's a possible patch that does this. It's very simple and does not
> affect the API, just the memory behaviour (I think):
>
> https://github.com/libvips/libvips/commit/9bdf5e8cda3e0c63584984282b1e36d97c50bb1a
>
> John
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

libnsgif and memory bombs

Hi all,

I had a thought regarding memory allocation in libnsgif.

At the moment, calling `gif_initialise()` will parse the GIF file and
allocate memory for rendering. You then call gif_decode_frame() to
decompress and render each frame of the animation.

However, this means just opening the GIF can trigger very large memory
allocations, with no chance for the caller to intervene, except by
putting a hard pixel limit into the bitmap_create() callback. For
example, a 20 byte GIF can cause a 17gb malloc.

How about delaying the allocation of the bitmap until the first call
to gif_decode_frame()? This would allow the caller to check the
detected width and height and apply some kind of size policy before
allowing rendering to occur.

Here's a possible patch that does this. It's very simple and does not
affect the API, just the memory behaviour (I think):

https://github.com/libvips/libvips/commit/9bdf5e8cda3e0c63584984282b1e36d97c50bb1a

John
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org