On 09/15/18 10:48 AM, John Emmas wrote:
On 15/09/2018 12:07, Magnus Bergman wrote:
Some mismatch in versions of libtiff
could for example be a reason. Otherwise you should probably file a bug
report with more information (perhaps to your distribution firstly).
Do you happen to know if the
On 16/09/2018 11:18, Emmanuele Bassi wrote:
The correct way to report issues for gdk-pixbuf:
1. use the issue tracker:
https://gitlab.gnome.org/GNOME/gdk-pixbuf/issues/new
Thanks Emmanuele - done!
___
gtk-devel-list mailing list
On Sun, 16 Sep 2018 at 10:47, John Emmas wrote:
> On 15/09/2018 18:48, John Emmas wrote:
> >
> > Do you happen to know if the tiff library has its own mailing list? I
> > haven't had much success in finding one
> >
>
> In fact I'll need the mailing list for gdk-pixbuf now - except that I
>
On 15/09/2018 18:48, John Emmas wrote:
Thanks Magnus. I've a feeling that the problem might come down to
struct alignment.
No, I was wrong about that. I've tracked the problem to commit
#ce52cefbbc in gdk-pixbuf (which brings me to the 2nd problem...)
On 15/09/2018 18:48, John Emmas
On 15/09/2018 12:07, Magnus Bergman wrote:
Some mismatch in versions of libtiff
could for example be a reason. Otherwise you should probably file a bug
report with more information (perhaps to your distribution firstly).
Thanks Magnus. I've a feeling that the problem might come down to
On Sat, 15 Sep 2018 09:47:33 +0100
John Emmas wrote:
> Sorry, I haven't been following this conversation but as a
> side-issue... I only noticed this morning that gdk-pixbuf doesn't
> seem to be able to load TIF images any more. I've attached a small
> file that won't load but I haven't managed
Sorry, I haven't been following this conversation but as a side-issue...
I only noticed this morning that gdk-pixbuf doesn't seem to be able to
load TIF images any more. I've attached a small file that won't load
but I haven't managed to load any TIF image from the ones I've tested
this
On Tue, 11 Sep 2018 13:22:17 +0200
Bastien Nocera wrote:
> On Tue, 2018-09-11 at 07:40 +0100, John Cupitt via gtk-devel-list
> wrote:
> > On Tue, 11 Sep 2018 at 03:11, Magnus Bergman
> > wrote:
> > > On Tue, 11 Sep 2018 00:07:27 +0200
> > > Bastien Nocera wrote:
> > > > No, it really
On Tue, 2018-09-11 at 07:40 +0100, John Cupitt via gtk-devel-list
wrote:
> On Tue, 11 Sep 2018 at 03:11, Magnus Bergman
> wrote:
> > On Tue, 11 Sep 2018 00:07:27 +0200
> > Bastien Nocera wrote:
> > > No, it really isn't:
> > >
On Tue, 11 Sep 2018 at 03:11, Magnus Bergman
wrote:
> On Tue, 11 Sep 2018 00:07:27 +0200
> Bastien Nocera wrote:
> > No, it really isn't:
> > https://www.cvedetails.com/vulnerability-list/vendor_id-1749/Imagemagick.html
> >
> > We want to have less CVEs, not more.
>
> I see what you mean. A few
On Tue, 11 Sep 2018 00:07:27 +0200
Bastien Nocera wrote:
> On Mon, 2018-09-10 at 22:29 +0200, Magnus Bergman wrote:
> > On Mon, 10 Sep 2018 11:31:42 +0200
> > Bastien Nocera wrote:
> >
> > I do use a library (or two). I've written one plugin that uses
> > giflib and one that uses
On Mon, 2018-09-10 at 22:29 +0200, Magnus Bergman wrote:
> On Mon, 10 Sep 2018 11:31:42 +0200
> Bastien Nocera wrote:
>
> > > I've written loader for GIF that simply wraps abydos. In lines of
> > > code it's about a quarter the size of the current loader, even
> > > including
> > > the GIF
On Mon, 10 Sep 2018 07:02:23 +
Debarshi Ray wrote:
> On Sun, Sep 09, 2018 at 02:57:30AM +0200, Magnus Bergman wrote:
> > Many fields of science deal with images of multi
> > gigabyte sizes. Ideally any image viewer should be able to handle
> > these too with the right plugin (probably using
On Mon, 10 Sep 2018 11:31:42 +0200
Bastien Nocera wrote:
> > I've written loader for GIF that simply wraps abydos. In lines of
> > code it's about a quarter the size of the current loader, even
> > including
> > the GIF plugin for abydos. It might even be slightly smaller with
> > the whole of
On Sun, 2018-09-09 at 01:23 +0200, Magnus Bergman wrote:
> On Fri, 07 Sep 2018 12:51:32 +0200
> Bastien Nocera wrote:
>
> > > > Gegl is great for image editing. But not as much for simple
> > > > viewing.
> > >
> > > This is debatable. If I'm viewing a 4000x4000 RGB image on a
> > > hidpi
> >
On Mon, Sep 10, 2018 at 09:40:13AM +0100, jcup...@gmail.com wrote:
> I make a gtk viewer that can display large images efficiently (over
> 100,000 x 100,000), linked above. I hit a few other issues:
>
> 1. You can't use a large ScrolledWindow and only paint the visible
> area, since you can
On Mon, 10 Sep 2018 at 08:02, Debarshi Ray wrote:
> > too with the right plugin (probably using GEGL in that case). But I
> > think the problem with large images (say 12000x12000 or so) is giving
> > it to the application as a pixmap. From my own tests it seams it's fine
> > at least as long as
On Sun, Sep 09, 2018 at 02:57:30AM +0200, Magnus Bergman wrote:
> Many fields of science deal with images of multi
> gigabyte sizes. Ideally any image viewer should be able to handle these
> too with the right plugin (probably using GEGL in that case). But I
> think the problem with large images
On Fri, 7 Sep 2018 17:28:04 +
Debarshi Ray wrote:
> Hey Magnus,
>
> I haven't yet worked my way through the whole thread. It's pretty
> long and will take me a while longer, but I did want to mention a
> few things before the weekend draws me away from the computer.
>
> On Wed, Sep 05,
On Fri, 07 Sep 2018 12:51:32 +0200
Bastien Nocera wrote:
> > > Gegl is great for image editing. But not as much for simple
> > > viewing.
> >
> > This is debatable. If I'm viewing a 4000x4000 RGB image on a hidpi
> > display I'm already pushing gdk-pixbuf and cairo to their limits
> > because
On Thu, 06 Sep 2018 13:03:03 -0500
Federico Mena Quintero wrote:
> On Wed, 2018-09-05 at 17:28 +0100, Emmanuele Bassi via gtk-devel-list
> wrote:
>
> > In the near future, I'll very likely deprecate most of GdkPixbuf's
> > API, except for the I/O operations; I'd also be happy to seal off
> >
On Wed, Sep 05, 2018 at 08:25:05PM +0200, Magnus Bergman wrote:
> Gegl is great for image editing. But not as much for simple viewing. It
> doesn't do animation
People have been creating and playing videos with it:
http://gegl.org/gcut.html
> Also it only loads images from the
> file system and
Hey Magnus,
I haven't yet worked my way through the whole thread. It's pretty
long and will take me a while longer, but I did want to mention a
few things before the weekend draws me away from the computer.
On Wed, Sep 05, 2018 at 12:02:45AM +0200, Magnus Bergman wrote:
> Over the years it has
On Thu, 2018-09-06 at 11:39 +0100, Emmanuele Bassi via gtk-devel-list
wrote:
> On Wed, 5 Sep 2018 at 19:25, Magnus Bergman <
> magnus.berg...@snisurset.net> wrote:
> > On Wed, 5 Sep 2018 17:28:22 +0100
> > Emmanuele Bassi wrote:
> >
> > > We're phasing out Cairo in favour of the CSS rendering
On Thu, 6 Sep 2018 11:39:59 +0100
Emmanuele Bassi wrote:
> On Wed, 5 Sep 2018 at 19:25, Magnus Bergman
> wrote:
>
> > On Wed, 5 Sep 2018 17:28:22 +0100
> > Emmanuele Bassi wrote:
> >
> > > We're phasing out Cairo in favour of the CSS rendering model,
> > > implemented on top of OpenGL and
On Wed, 2018-09-05 at 17:28 +0100, Emmanuele Bassi via gtk-devel-list
wrote:
> In the near future, I'll very likely deprecate most of GdkPixbuf's
> API, except for the I/O operations; I'd also be happy to seal off
> most of its internals, within the ABI stability promise, to avoid
> leakage of
On Thu, 6 Sep 2018 at 11:40, Emmanuele Bassi via gtk-devel-list
wrote:
> On Wed, 5 Sep 2018 at 19:25, Magnus Bergman
> wrote:
>> Gegl is great for image editing. But not as much for simple viewing.
>
> This is debatable. If I'm viewing a 4000x4000 RGB image on a hidpi display
> I'm already
On Wed, 5 Sep 2018 at 19:25, Magnus Bergman
wrote:
> On Wed, 5 Sep 2018 17:28:22 +0100
> Emmanuele Bassi wrote:
>
> > We're phasing out Cairo in favour of the CSS rendering model,
> > implemented on top of OpenGL and Vulkan, as it's the API that most
> > closely matches the requirements of GTK.
On 09/05/2018 06:57 PM, Nicolas Dufresne wrote:
> I've replied to a comment about sandboxing image loading to prevent
> possible crash buffer overflow from happening. You are now focusing on
> an optimization. I believe you should start a new thread.
It's relevant because it is the same as the
Le mercredi 05 septembre 2018 à 18:43 -0700, Christian Hergert a écrit :
> On 09/05/2018 06:18 PM, Nicolas Dufresne wrote:
> > Is there any benchmark that would justify this added complexity ? Also,
> > there will be more context switch, so cache misses will take more time
> > then just loading
On 09/05/2018 06:18 PM, Nicolas Dufresne wrote:
> Is there any benchmark that would justify this added complexity ? Also,
> there will be more context switch, so cache misses will take more time
> then just loading the icon directly.
Just because you've decoded into a non-shareable page of memory
On Wed, 5 Sep 2018 17:47:57 -0400
Ray Strode wrote:
> hi,
>
> On Tue, Sep 4, 2018, 6:19 PM Magnus Bergman
> wrote:
>
> > Over the years it has been discussed from time to time to replace
> > gdk-pixbuf with something else[1][2].
>
> [...]
>
> > I finally took some time to design an
> >
Le mercredi 05 septembre 2018 à 17:49 -0700, Christian Hergert a
écrit :
> On 09/05/2018 05:03 PM, Nicolas Dufresne wrote:
> >
> > For foreign image, yes, but for system icons, that's just an
> > overhead.
>
> System icons should be using mmap'able caches that avoid any runtime
> overhead and
On 09/05/2018 05:03 PM, Nicolas Dufresne wrote:
>
> For foreign image, yes, but for system icons, that's just an overhead.
System icons should be using mmap'able caches that avoid any runtime
overhead and allows read-only page-sharing between processes.
Le mer. 5 sept. 2018 17:48, Ray Strode via gtk-devel-list <
gtk-devel-list@gnome.org> a écrit :
> hi,
>
> On Tue, Sep 4, 2018, 6:19 PM Magnus Bergman
> wrote:
>
>> Over the years it has been discussed from time to time to replace
>> gdk-pixbuf with something else[1][2].
>
> [...]
>
>> I finally
hi,
On Tue, Sep 4, 2018, 6:19 PM Magnus Bergman
wrote:
> Over the years it has been discussed from time to time to replace
> gdk-pixbuf with something else[1][2].
[...]
> I finally took some time to design an
> image loading library on top of cairo
[...]
> abydos, which at least
> suits my
On Wed, 5 Sep 2018 17:28:22 +0100
Emmanuele Bassi wrote:
> Hi;
>
> On Tue, 4 Sep 2018 at 23:19, Magnus Bergman
> wrote:
>
> > Over the years it has been discussed from time to time to replace
> > gdk-pixbuf with something else[1][2]. Something was even in the
> > making (I guess over ten
Hi;
On Tue, 4 Sep 2018 at 23:19, Magnus Bergman
wrote:
> Over the years it has been discussed from time to time to replace
> gdk-pixbuf with something else[1][2]. Something was even in the making
> (I guess over ten years ago) but it never replaced gdk-pixbuf
> apparently. Now I don't even
Over the years it has been discussed from time to time to replace
gdk-pixbuf with something else[1][2]. Something was even in the making
(I guess over ten years ago) but it never replaced gdk-pixbuf
apparently. Now I don't even remember what it was called. And something
else called pig was
39 matches
Mail list logo
