Some bug fixes for the framebuffer frontend
by Alex Friesenhahn
Hi,
First of all I want to say thanks for all the hard work that has been put
into this browser over the years!
I was looking for a fast and lightweight browser to port to the reMarkable,
which is an E-Ink tablet with a single-core ARMv7 processor and 500MB RAM.
My efforts to get it running were successful, and I am absolutely amazed by
the performance of Netsurf on this device. Really great work!
I found some bugs in the framebuffer frontend. which I have mostly fixed in
my fork, but I would like to keep the changes in my fork as minimal as
possible.
These fixes may not be in a fitting location, or could be improved (C
programming is very new to me), but perhaps they can serve as a base for a
fix that can be applied to your codebase.
- The icons in the toolbar are not resized horizontically, just vertically,
when setting the toolbar height via fb_toolbar_size.
https://github.com/alex0809/netsurf-base-reMarkable/commit/134cd55cbf4d69...
- On-screen keyboard close button is set to static 18 pixel size, size
should be dependent on fb_furniture_size instead
https://github.com/alex0809/netsurf-base-reMarkable/commit/7b6860e26c4828...
- Some wrong mappings on the on-screen keyboard: slash and backslash is
swapped, quote key is mapped to l key
https://github.com/alex0809/netsurf-base-reMarkable/commit/0a44646f4f8fe1...
- The on-screen keyboard scrolling and page change is bugged:
When you keep the keyboard open and scroll, the image of the keyboard is
scrolled as part of the content.
When you change the page, the keyboard remains in open state but new
webpage content is drawn over it.
I haven't got around to fixing this yet. Hints on how to approach this are
appreciated!
- This one is a bit more subtle, and I think it only becomes apparent in my
more specific use case:
When scrolling via mouse-drag, the
desktop/browser_window.c#browser_window_set_scroll function receives the
rect to scroll to, and forwards that to set_scroll on the gui-window.
Issue is, the content size in the framebuffer frontend depends on the
current scale factor, but the browser_window_set_scroll sends the new rect
without the scale factor calculated in.
When continuously scrolling, like is done in the original implementation,
this is not noticeable, because each scroll will only be by a few pixels.
But to adapt the scrolling for the E-Ink display, I set fixed scroll
increments. And what happens is that e.g. when you set it to scroll 100
pixels, it will actually only scroll (100 / scale) pixels.
https://github.com/alex0809/netsurf-base-reMarkable/commit/8658c931c2cf6d...
Regards,
Alex
2 years, 8 months
- 1
- 0
libnsgif and memory bombs
by jcupitt＠gmail.com
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/9bdf5e8cda3e0c63584984282b1e36d...
John
2 years, 8 months
- 2
- 4
- ← Newer
- 1
- Older →