Try CI#1028 only for now, the resize with content is cool as effect but a bit sluggish for real usage, however the effect's result seems a bit faster turning off the antialias fonts on the prefs.
No corruptions by the way
To be honest i will revert back, maybe you can offer this feature as optional, activable via the Choice textfile or so
OK, it's added as an option, I suppose that covers everybody's preferences. You can twiddle reformat_delay too to change resizing responsiveness. It can be changed when resize_with_contents is off too, but there's no benefit to doing so.
I tried to speed up anti-aliased text, but there doesn't seem to be any hardware accelerated way of plotting arbitrarily-sized alpha templates.
Will do, thanks Chris Indeed right now i'm using NetSurf with antialias disabled because this is the only way i found to have a smoth scrolling, hope you can found a method to optimize it a little bit
When in the About requester, pressing Esc spawns a new browser window with the NetSurf Licence. While the requester does what it is supposed to do (= close as if the last requester gadget was pressed), the resulting behaviour is a GUI blooper because the user does NOT expect the requester to open anything upon pressing Esc.
Unless I'm mistaken, there's no way of changing/disabling the default Return/Esc keyboard shortcuts. The only options I have is to re-arrange the buttons so Esc closes the requester and does nothing (but Return will then do something instead), or add a "Cancel" button so we have [ OK | Licence | Credits | Cancel ], which looks a bit silly.
The overkill option is to make the About requester into a standard window, which is probably what I ought to do as I should be able to embed credits/licence into it then (this is what the GTK version does IIRC). Anyway, that's not happening before 3.0 release.
Unless I'm mistaken, there's no way of changing/disabling the default Return/Esc keyboard shortcuts.
AFAIK that's correct.
Quote:
The overkill option is to make the About requester into a standard window
What I'd probably do if I went this route is make a window with tabs for switching between licence, credits etc., and only one button - "OK" - at the bottom.
1) Just for info, I have encountered a lag problem with NetSurf 3.0 (json and jsoff version)
On my x1000 dual gfx setup (RadeonHD 6670 and Radeon 9250), Netsurf is verry laggy. Mouse stops to respond for 1 second every 2 or 3 seconds.
I found the problem, it is my dual gfx cards setup.
When I launch NetSurf (1 or many instances is the same) it takes memory on my second cards (Radeon9250) even if my Workbench is on the RadeonHD card.
On the grab below, the right SysMon shows the initial gfx memory consumption (0mb for Radeon9250) The left SysMon shows that as soon that I launch one instance of NetSurf (json or jsoff) 8 mb of memory are consumed on the 9250 card.
@AmigaBlitter Sounds like you've installed 3.0 and are then trying to run 2.9. You definitely aren't running one of the development builds that are the subject of this thread anyway
I *might* have fixed that problem, but only for 32-bit screenmodes. It *might* have broken NetSurf for anybody using little-endian 32-bit modes (BGRA) - is there anybody who does?
Unfortunately the auto-builder seems to be frozen at the moment, but when there's a build beyond the timestamp of this message can you give it a try please?
@Chris I delete my previous install and install new version (3.0a-json). On running it says "Neturf is running out of memory. Please free some memory and try again", while i have 800mb free. In shell console i have a lot of output of this kind:
Quote:
libpng warning: Application was compiled with png.h from libpng-1.2.44 libpng warning: Application is running wiht png.c from libpng-1.4.4 libpng warning: Incompatible libpng version in application and library
I of course understand what it mean, but imho "right" libpng should be copied by netsurf installer already ?
Hmm, ok, obviously friend bitmaps aren't the way to ensure memory gets allocated for the correct gfx card.
@kas1e
I can't remember whether it installs one or not (I think it does). It sounds like you might have libpng.so (with no extension) soft-linked to libpng.so.14 - which will never work, as Cairo won't work with anything newer than libpng 1.2.
I can't remember whether it installs one or not (I think it does). It sounds like you might have libpng.so (with no extension) soft-linked to libpng.so.14 - which will never work, as Cairo won't work with anything newer than libpng 1.2.
But if i have it like this, it mean some SW do it. I.e. changing it back, will broken another ones :( Maybe in case with libpng it make sense to build it statically to netsurf ?
zzd10h wrote: Please, don't waste your time with my problem, we must be not a lot of amigans to have a dual gfx setup...
I'm curious now. I've posted a question over on the official forums, if anything useful comes out of it then your problem might get fixed.
@kas1e
The development builds are static, you could use the latest of those instead. libpng.so should always be linked to libpng12.so as libcairo.so points to libpng.so and will not work with any later version.