Feature request #1016
mysterious white box obscures data in the map window
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Low | ||
| Assignee: |  Marco Hugentobler | ||
| Category: | - | ||
| Pull Request or Patch supplied: | Resolution: | fixed | |
| Easy fix?: | No | Copied to github as #: | 11076 |
Description
We are currently working on a project for which we have data being digitized by a team in Jordan using QGIS. We have encountered an issue that is slowing work where members of our team have been unable to see data in the map window while digitizing new polygon features because a mysterious white box appears after the third vertex is added that obscures data in the map window. They are using version 0.9.0 and I have been thus far unable to find any information or discussion about such an error. I was curious if this error was something you were aware of at all in that version. One of my colleagues suggested that it may be a graphic driver issue, but I have been unable to locate system requirements for QGIS anywhere in the documentation. Is there anywhere that I can locate this information?
digitizing_obscured_mask_problem.png - Image of rendering problem with disappearing vectors during editing (20.4 KB)
zoom_box_obscuring_problem.png - Similar problem occurring during use of bbox zoom tool where the space behind tool coordinates covers vectors (14.2 KB)
patch_for_1016.txt 
- fix white box
(850 Bytes)
patch2_for_1016.txt
- fix root cause of white box problem
(1.23 KB)
Associated revisions
applied patch from smizuno to fix #1016
git-svn-id: http://svn.osgeo.org/qgis/trunk/qgis@9142 c8812cc2-4d05-0410-92ff-de0c093fc19c
applied patch from smizuno to fix #1016
git-svn-id: http://svn.osgeo.org/qgis/trunk@9142 c8812cc2-4d05-0410-92ff-de0c093fc19c
History
#1
Updated by Jürgen Fischer almost 16 years ago
see also #1093
#2
Updated by springmeyer - almost 16 years ago
I have been running into this problem as well, using 0.10.0 on mac osx. It does not seem occur all the time, and I have not been able to track down a way to predictably trigger it when not happening. However, when it does happen(estimated 60% of qgis use for me) it makes accurate digitization extremely difficult and troublesome.
It seems closely related to the similar issue of having the bounding box tool draw a solid grey polygon rather than a transparent polygon bbox. Additionally when the bbox is dragged over any vector features and then moved it leaves pure white. This also seems to occur will all other tools that have some drag or draw component.
Two screenshots are attached of the digitizing tool and bbox zoom tool causing rendering problem.
Changing the rendering properties in preferences does not seem to effect the problem.
#3
Updated by Steven Mizuno over 15 years ago
more information (based on Windows builds):
(a work-around) I have discovered that using the Pan Map tool, then dragging the mouse to pan even just a little bit makes the problem go away for as long as the QGIS session is used. It is critical that the map be panned by the mouse gesture; just clicking on the map or using any other tool or even keyboard panning does not affect the problem.
In addition, if a tool bar is moved around and the map canvas is resized so the toolbar can be docked also makes the problem go away.
The white box is actually the background color.
Most any tool that involves a mouse drag gesture will cause the obscuring box in at least some situations.
Using the zoom in/zoom out tools may result in a box that is partially obscuring the map, depending on how fast the mouse is dragged.
A tool bar that drops over the map canvas also leaves a blank area behind.
Once the map is panned by the mouse there is still a box that flashes momentarily while zooming or panning. It changes size with zooming and moves with panning, so I believe there is an object hanging around on some layer.
The problem first appeared with version 0.9.0, I believe.
I have not noticed this problem on my Linux installation, but also have not tested very much.
#4
Updated by Steven Mizuno over 15 years ago
I have found that white boxes are caused by the order of setting a new size for mMap and mScene in the QgsMapCanvas::resizeEvent(QResizeEvent * e) function. I believe that mScene should be set after mMap. The order doesn't seem to be a factor except at program startup.
While I was poking around in QgsMapCanvas.cpp I took the liberty of adding zoom in, zoom out abilities by the PageUp, PageDown keys respectively. This is something that I had considered for an enhancement as it is useful to have zooming if you can pan via the keyboard. Also, not all pointing devices have a wheel. They use the zoom function that the mouse wheel zoom uses, hence the same zoom factor.
The patch I have provided fixes the most annoying part of the white box problem and adds the keyboard zoom. There still are white boxes that flash momentarily when the map is redrawn after certain tools have been used.
Have tested on Windows and Linux, but not Mac.
#5
Updated by Marco Hugentobler over 15 years ago
Hi Smizuno
I'm going to review this patch.
Thanks,
Marco
#6
Updated by Marco Hugentobler over 15 years ago
- Resolution set to fixed
- Status changed from Open to Closed
Applied in d6e4c29b (SVN r9143).
Thanks!
Marco
#7
Updated by Steven Mizuno over 15 years ago
- Status changed from Closed to Feedback
- Resolution deleted (
fixed)
I reopen this ticket as I now have a good explanation of why the problem occurs and a further patch to fix it.
After reviewing (again... and again) the QGraphicsScene and QGraphicsItem classes, I found that prepareGeometryChange() needs to be called before changing a QGraphicsItem's geometry.
This is the root cause of the white boxes (artifacts of rubberbands and other objects) on the map canvas. The mapcanvasmap had its size changed, but the mapcanvas didn't know about it, therefore not redrawing its objects at the new size.
I have tested this by reverting to the previous order in QgsMapCanvas where the scene size was set, then the map size was set. Then prepareGeometryChange() is called in QgsMapCanvasMap::resize(). Now, there are no artifacts.
Still, it is better that the scene size is set after the map size is changed, as the scene size change updates indexes as necessary.
The patch provided adds the prepareGeometryChange() call in QgsMapCanvasMap::resize() and updates the note about the problem in QgsMapCanvas::resizeEvent().
#8
Updated by Marco Hugentobler over 15 years ago
Applied to trunk and to 1.0 branch.
Thanks!
Marco
#9
Updated by Marco Hugentobler over 15 years ago
- Resolution set to fixed
- Status changed from Feedback to Closed
#10 Updated by Anonymous over 14 years ago
Milestone Version 1.0.0 deleted