GNOME Bugzilla – Bug 528165
Enhance the scale operation of the screenshot image when there is no data in the tree model
Last modified: 2008-05-08 18:37:20 UTC
Please describe the problem: Currently we are just adapting the screenshot to the place we have to paint the widget when there is no information in the tree model, we are not considering any proportion. We should scale it keeping the proportion because in other case the drawing is distorted. The code of this scaling can be found in the expose function: if (priv->memento != NULL) { gint w, h; w = cairo_image_surface_get_width (priv->memento); h = cairo_image_surface_get_height (priv->memento); cairo_clip (cr); cairo_scale (cr, (gdouble) rchart->allocation.width/w, (gdouble) rchart->allocation.height/h); cairo_set_source_surface (cr, priv->memento, 0, 0); cairo_paint (cr); } The problem is described and was pointed out in this bug: https://bugs.edge.launchpad.net/ubuntu/+source/gnome-utils/+bug/216804 Steps to reproduce: You can check the problem in all the versions, just resize the window when rescanning a directory. In that moment the tree model is empty and the widget stored a screenshot of the last ringschart which it is going to use to draw it with a grey transparency over it. Actual results: Expected results: Does this happen every time? Yes Other information:
Created attachment 109324 [details] [review] simple patch for ringchart scaling simple patch for the scalation issue in the ringchart widget
Comment on attachment 109324 [details] [review] simple patch for ringchart scaling This is a first and simplistic approach to solve this bug: the scalation factor is proportional to the minimal side size.
the logic sounds correct to me. I have not checked the reusult though, so a couple of questions: - is the resulting drawing still centered? - is the sourrounding area (the part of the largest size where we don't draw anymore) all cleared and repainted so that there are no leftover artifacts? If the answer is yes to both those questions the patch looks good to commit to me.
- No :S - Yes But even the main problem is not fixed. I'm sorry about this lousy patch. I was excited because it was my first one, and I didn't verify it correctly. I'll give it another try.
Created attachment 109612 [details] [review] scale operation enhancement This is an improvement of the previous patch. Now the scaling operation is smooth without deformations nor clipping, as a user would expect. I think the patch is correct now.
Last patch apparently works well, and the patch looks good. if no one finds any problem I'm going to upload the patch. Thanks Víctor :-)
looks good to me, my only concern is: + p = MIN (rchart->allocation.width / (1.0 * w), + rchart->allocation.height / (1.0 * h)); can w or h be 0 under some pathologic conditions? If yes we need to check that to avoid division by 0.
Created attachment 109632 [details] [review] scale operation enhacement 3 I can't foresee any scenario where the w or the h could be equal to zero. Any way, this new patch could deal with that situation preventing the division by zero.
Uploaded the patch to the svn, thanks Victor ;-)