| 187 | | * When you have time, write here why using |
|---|
| 188 | | * gtk_widget_queue_draw_area() is wrong. |
|---|
| | 187 | * GtkImageView aggresively caches the scaled image data. This |
|---|
| | 188 | * behaviour is most often beneficial and makes the widget very |
|---|
| | 189 | * fast. For example, try opening a very large image (4000x2000 |
|---|
| | 190 | * pixels or so) in GtkImageView. The widget will spend some time |
|---|
| | 191 | * bilinearly downsampling the image at the start. Then try |
|---|
| | 192 | * minimizing and unminimizing the window. The image will reappear |
|---|
| | 193 | * immidately because the view has cached it. |
|---|
| | 194 | * </para> |
|---|
| | 195 | * <para> |
|---|
| | 196 | * However, this feature means that a client application must |
|---|
| | 197 | * signal to the view when it changes the pixels on the pixbuf |
|---|
| | 198 | * that the view shows. The right way to do that is to use the |
|---|
| | 199 | * gtk_image_view_set_pixbuf() function with the old pixbuf as the |
|---|
| | 200 | * argument. In particular, code that merely tries to update the |
|---|
| | 201 | * view by requesting that it should be redrawn will not work. |
|---|
| | 202 | * </para> |
|---|
| | 203 | * <informalexample> |
|---|
| | 204 | * <programlisting> |
|---|
| | 205 | * // Do some operation on the pixbuf data here |
|---|
| | 206 | * gtk_widget_queue_draw_area (10, 10, 50, 50) // Incorrect! |
|---|
| | 207 | * </programlisting> |
|---|
| | 208 | * </informalexample> |
|---|
| | 209 | * <para> |
|---|
| | 210 | * In future versions of GtkImageView a method will be added that |
|---|
| | 211 | * marks an area of the pixbuf as dirty and forces the view to |
|---|
| | 212 | * flush its cache. |
|---|
