On Sat, Feb 16, 2013 at 01:13:03AM +0100, Raphaël Droz <[email protected]>
wrote:
> I did some preliminary attempts using the raw xlib and use of rxvt_img
> api but I must admit it was hard and time-consuming [no offense here,
> just my small experience, and some impatience]. (but to be exhaustive, I
> even tried Cairo).
The advantage of raw xlib and rxvt_img over gdk pixbuf is not that it
easier, nicer, cooler or anything, but that it actually works and is
maintained - when I switch to an "unusual" bit depth (such as 30bpp) then
everything that uses gdk pixbuf simply fails in various ways - mostly gtk+
programs show black pictures instead of what they are supposed to show.
In any case, the rxvt_img API is much simpler than gdk pixbuf, so while
you might find it hard and time-consuming, it less less hard and less time
consuming than gdk pixbuf to learn and use.
However, the APIs have different goals - pixbuf has no functionality for
hardware acceleration and server-side image manipulation, while rxvt_img is
only about that.
> When I finally found gdk_pixbuf_new_from_file*() and
> gdk_pixbuf_xlib_render_to_drawable() and got them working in a couple of
> minutes I considered them as a godsend.
Feel free to use it for your own code, but for urxvt, we need something
that works not just on your box. 30bpp isn't that uncommon, and is likely
to become more common over time.
In any case, this is the rxvt_img equivalent of your example:
$pixbuf = $term->new_img_from_file ($path);
Your argument that this is somehow harder than gdk pixbuf is rather
difficult to understand.
> These functions behave exactly how I'd expect from a nice image library.
That can only be because you don't expect these functions to actually
work.
> 1) could you point me to any reference on gdk pixbuf xlib non-maintenance ?
I could, but I don't see it as useful use of my time.
> 2) don't you think that bugs related to different screen depth should
> be, as much as possible, fixed there,
No, since we don't use that code, so bug fixes there have zero relevance.
> with the objective of a sane and long-term approach, rather than trying
> to workaround them specifically in urxvt ?
We are not working around any gdk pixbuf bugs in urxvt.
> Still talking about a C-based implementation, and about the structure
> ("rxvt_img api"): do you mean that rxvt_img should be extended (flags,
> filename, ...) and then a vector of rxvt_img should be preferred to the
> current vector of _InTermImage ?
No, I mean what I wrote in my original reply.
> Does it mean (in the case of a perl implementation), that pixbuf should
> live fully in the perl context ?
No, pixbuf shouldn't live anywhere - there is a perfectly fine API
existing for image loading and server uploading - if you disagree, you
need to use some real arguments.
> Indeed Gtk2::Gdk::Pixbuf bindings contain render_to_drawable(), it _may_
> not be impossible to grab or build a Gtk2::Gdk::Drawable.
As explained a few times already, IT DOES NOT WORK, so any attempt to use
it is moot.
> Although I take note that a full-C implementation isn't inherently an option
> you'd reject, you'd prefer as much code as possible to leave in perl.
No - I prefer not bloating the core with what doesn't belong
there. Refresh does belong there, at least partially, for efficiency
reasons, and so do any hooks for extensions.
The core already has all of the imaging api needed for this usage (also
exposed to extensions), and I think it can already be done with the
existing plugin API, at least to the same extent as shown in your patch.
> > Resizing is an interetsing problem - if text around images is allowed,
> > then doing it properly would require reflowing text around images, which
> > is quite a big project imho. Can't imagine anything simpler to do the job,
> > though.
>
> Instead of linking to one of libcss, libcroco or ccss I tried to define
> a limited set of presentational flags and didn't took into account text
> flow.
I am not sure how css came into the discussion - the problem is text flow,
which has nothing to do with css. The problem with text flow is that text
resizes differently than images, and urxvt needs to do something useful in
that case.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / [email protected]
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
rxvt-unicode mailing list
[email protected]
http://lists.schmorp.de/cgi-bin/mailman/listinfo/rxvt-unicode
