search

maltanar / watchntouch

Automatically exported from code.google.com/p/watchntouch
2 stars 2 forks source link

Drawing system must be converted to raster #2

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
The current vector-based drawing system has three major issues:

 - low performance on embedded devices
 - large SVG files due to QSvgGraphicsItem being loaded as bitmap
 - cannot use eraser tool

thus the drawing system has to be moved to a bitmap/raster based one.

Original issue reported on code.google.com by malta...@gmail.com on 13 Mar 2011 at 6:49

GoogleCodeExporter commented 9 years ago 
I'm currently working on this, it's almost finished as of commit r56.

Original comment by malta...@gmail.com on 13 Mar 2011 at 7:49

GoogleCodeExporter commented 9 years ago 
I have done some testing and caught the following defects: (These points are 
about r56)

1 - After drawing something to the board, clicking on next/back buttons makes 
the program immediately exit. It gives such output:

..
QPicture::play: Invalid command 240
QPicture::play: Invalid command 132
QPicture::play: Format error
saving to 
"/home/utku/w&t/deneme/trunk/iwbc_demo-build-desktop/annotations/4c4485902a82429
ec4842a48d5e2c4ab/annotation_2_0.wta"
The program has unexpectedly finished.

2 - When I use the mouse to draw to the board rather than ir-pen, I can not 
draw smooth shapes or lines. For example, When I try to draw a circle, either 
only a line or a polygon consisting several straight lines appears. However, 
when I start to use the irpen, the problem has been disappeared.

3 - While deleting a line, it deletes after the mouse releases, not as soon as 
the mouse passes over the line. Moreover, *sometimes*, it immediately exits 
from the program just like in 1. Note that no explicit reproducing steps could 
be found. The output is very like to the one in 1:

..
QPicture::play: Invalid command 240
QPicture::play: Invalid command 118
The program has unexpectedly finished.

Original comment by utkusi...@gmail.com on 19 Mar 2011 at 8:19

GoogleCodeExporter commented 9 years ago 
Must be resolved in the first development snapshot milestone, adding milestone 
flag. Melike will carry out the testing and I will be making the necessary 
changes.

Original comment by malta...@gmail.com on 20 Mar 2011 at 3:38

GoogleCodeExporter commented 9 years ago 
1) I was able to reproduce this. Probably was due to some memory issues while 
creating the QPicture's that store the drawing information for a single drawing 
step (used for undo/redo). Should be fixed in r61.

2) Could not reproduce, still investigating.

3) The erase-on-mouseup is due to the way the erasing algorithm is implemented. 
I'm looking for an alternative solution which will look more user-friendly.

Original comment by malta...@gmail.com on 20 Mar 2011 at 4:01

GoogleCodeExporter commented 9 years ago

Original comment by malta...@gmail.com on 23 Mar 2011 at 3:48

GoogleCodeExporter commented 9 years ago 
I implemented a sort of a workaround for the erase-on-mouse-up, now we have 
white (not transparent) rectangles while the mouse is moving, which later turn 
transparent. I think it looks better in the sense of giving the user an idea of 
which region is being erased.

Original comment by malta...@gmail.com on 23 Mar 2011 at 8:12

GoogleCodeExporter commented 9 years ago 
Changes for round cap and join style & fixed composition mode which allow for 
correct undo in all cases are also committed as of r70.

There's only one bug left that I'm aware of: if the mouse is moved beyond the 
drawing area boundaries while drawing, this will result in incorrect 
undo/redo's due to incorrect determination of the bounding rectangle. Still 
working on a fix for this.

Original comment by malta...@gmail.com on 23 Mar 2011 at 9:15