1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Differences between Imlib and gdk-pixbuf</title>
<meta name="generator" content="DocBook XSL Stylesheets V1.75.2">
<link rel="home" href="index.html" title="GDK-PixBuf Reference Manual">
<link rel="up" href="apa.html" title="Appendix A. Porting applications from Imlib to gdk-pixbuf">
<link rel="prev" href="apa.html" title="Appendix A. Porting applications from Imlib to gdk-pixbuf">
<link rel="next" href="apas03.html" title="Converting Applications to gdk-pixbuf">
<meta name="generator" content="GTK-Doc V1.14 (XML mode)">
<link rel="stylesheet" href="style.css" type="text/css">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<table class="navigation" id="top" width="100%" summary="Navigation header" cellpadding="2" cellspacing="2"><tr valign="middle">
<td><a accesskey="p" href="apa.html"><img src="left.png" width="24" height="24" border="0" alt="Prev"></a></td>
<td><a accesskey="u" href="apa.html"><img src="up.png" width="24" height="24" border="0" alt="Up"></a></td>
<td><a accesskey="h" href="index.html"><img src="home.png" width="24" height="24" border="0" alt="Home"></a></td>
<th width="100%" align="center">GDK-PixBuf Reference Manual</th>
<td><a accesskey="n" href="apas03.html"><img src="right.png" width="24" height="24" border="0" alt="Next"></a></td>
</tr></table>
<div class="sect1" title="Differences between Imlib and gdk-pixbuf">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="id496665"></a>Differences between <span class="application">Imlib</span> and <span class="application">gdk-pixbuf</span>
</h2></div></div></div>
<p>
Generally, applications that use <span class="application">Imlib</span> do not have to be
changed extensively to use <span class="application">gdk-pixbuf</span>; its simple and
flexible API makes things easy. This section describes the
differences between <span class="application">Imlib</span> and <span class="application">gdk-pixbuf</span>; you should take
these into account when modifying your applications to use
<span class="application">gdk-pixbuf</span>.
</p>
<div class="sect2" title="Initialization">
<div class="titlepage"><div><div><h3 class="title">
<a name="id478921"></a>Initialization</h3></div></div></div>
<p>
The <span class="application">gdk-pixbuf</span> library does not need to be initialized.
</p>
<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
<h3 class="title">Note</h3>
<p>
In GNOME applications you normally don't need to
initialize <span class="application">Imlib</span>, as <code class="function">gnome_init()</code>
calls <code class="function">gdk_imlib_init()</code> automatically.
</p>
</div>
</div>
<div class="sect2" title="Memory management">
<div class="titlepage"><div><div><h3 class="title">
<a name="id528688"></a>Memory management</h3></div></div></div>
<p>
The <span class="application">gdk-pixbuf</span> library provides a simple, well-defined
memory management mechanism for images in the form of
reference counting. This makes it very convenient to use
for large-scale applications that need to share images
between different parts of the program. In stark contrast,
<span class="application">Imlib</span> has a terribly complex mechanism of an image and
pixmap cache which makes it very hard for applications to
share image structures between different parts of the
program. Unfortunately this mechanism makes things very
prone to memory leaks and tricky bugs.
</p>
<p>
The basic principle in <span class="application">gdk-pixbuf</span> is that when you obtain
a new <a class="link" href="gdk-pixbuf-gdk-pixbuf.html#GdkPixbuf">GdkPixbuf</a> structure,
it is created with an initial reference count of 1. When
another part of the program wants to keep a reference to the
pixbuf, it should call <code class="function">g_object_ref()</code>;
this will increase the reference count by 1. When some part
of the program does not need to keep a reference to a pixbuf
anymore and wants to release the pixbuf, it should call
<code class="function">g_object_unref()</code>; this will decrease
the reference count by 1. When the reference count drops to
zero, the pixbuf gets destroyed or
<span class="emphasis"><em>finalized</em></span> and its memory is freed.
</p>
<p>
For applications that need to implement a cache of loaded
images, <span class="application">gdk-pixbuf</span> provides a way to hook to the last
unreference operation of a pixbuf; instead of finalizing the
pixbuf, the user-installed hook can decide to keep it around
in a cache instead.
</p>
<p>
Finally, <span class="application">gdk-pixbuf</span> does not provide a cache of rendered
pixmaps. This is unnecessary for most applications, since
the scaling and rendering functions are quite fast and
applications may need to use subtly different values each
time they call these functions, for example, to take into
account dithering and zooming offsets.
</p>
<p>
Most applications will simply need to call
<code class="function">g_object_ref()</code> when they want to keep
an extra reference to a pixbuf, and then
<code class="function">g_object_unref()</code> when they are done
with it.
</p>
</div>
<div class="sect2" title="The Rendering Process">
<div class="titlepage"><div><div><h3 class="title">
<a name="id522182"></a>The Rendering Process</h3></div></div></div>
<p>
The <span class="application">gdk-pixbuf</span> library has the policy of always rendering
pixbufs to GDK drawables you provide; it will not create
them for you. This is in general more flexible than
<span class="application">Imlib</span>'s policy of always creating a pixmap and making you
use that instead.
</p>
<p>
The disadvantage of always having a pixmap created for you
is that it wastes memory in the X server if you intend to
copy that rendered data onto another drawable, for example,
the final destination window or a temporary pixmap for
drawing. This is the most common case, unfortunately, so
the <span class="application">Imlib</span> policy introduces unnecessary copying.
</p>
<p>
Also, <span class="application">Imlib</span> can only render pixmaps that are the whole
size of the source image; you cannot render just a subset
region of the image. This is inconvenient for applications
that need to render small portions at a time, such as
applications that do scrolling. Since the whole image must
be rendered at a time, this can lead to performance and
memory usage problems.
</p>
<p>
The <span class="application">gdk-pixbuf</span> library lets you render any rectangular
region from an image onto any drawable that you provide.
This lets the application have fine control the way images
are rendered.
</p>
</div>
</div>
<div class="footer">
<hr>
Generated by GTK-Doc V1.14</div>
</body>
</html>
|
