Moving ahead in inkscape development..
Hello all,
I had previously introduced myself as a GSOC 2010 aspirant. I am devoting myself to the idea of c++ifying(in Object Oriented manner) the inkscape code. For that I am trying to move into the code and traversing, but due to its vastness am facing problems in it. I got hold of a very old bug, "Y Scale inversion" -> https://bugs.launchpad.net/inkscape/+bug/170049. As i have seen the heat on this, this bug is of a very wide scope and so can actually help me to involve myself with *much* of the inkscape codebase. So it is my urgent and honest request to inkscape developers as well as corresponding GSOC mentors to just direct me as to where in the code I should start tracking and removing the bug. I will be glad.
Thanking You.
Yours sincerely,
2010/3/26 Abhishek Sharma <spyzer.abhishek0@...400...>:
Hello all, I had previously introduced myself as a GSOC 2010 aspirant. I am devoting myself to the idea of c++ifying(in Object Oriented manner) the inkscape code. For that I am trying to move into the code and traversing, but due to its vastness am facing problems in it. I got hold of a very old bug, "Y Scale inversion" -> https://bugs.launchpad.net/inkscape/+bug/170049. As i have seen the heat on this, this bug is of a very wide scope and so can actually help me to involve myself with much of the inkscape codebase. So it is my urgent and honest request to inkscape developers as well as corresponding GSOC mentors to just direct me as to where in the code I should start tracking and removing the bug. I will be glad. Thanking You. Yours sincerely, -- Abhishek Sharma
This is going to be rather involved. First you should try changing SPDesktop::dt2doc and SPDesktop::doc2dt to return an identity matrix, and look what breaks when you do this. In general, look at what SPDesktop's methods and sp_item_i2d_affine (in sp-item.cpp) do. What we need is changing the "desktop" coordinate system to be equal to the "document" coordinate system.
I heard you are working on code in src/ui/view/edit-widget.cpp. This code is dead and EditWidget is never instantiated. Start at src/desktop.cpp and work from there.
Regards, Krzysztof
Hello,
As was told to me I went for the dt2doc and doc2dt functions to start my bug-traversal. These functions, as i found out , return a locally(object scope) stored Matrix namely _doc2dt and with a bit of searching i was able to figure out that _doc2dt is initialized by the class Scale defined in transforms.cpp. From there the Matrix constructor gets called; but what i also noticed was that, at implementation level the _doc2dt was not a matrix but an array of size 6 and if logically seen as matrix -> _doc2dt has 3x2 dimensions, so i didn't quite get as to how it can be an identity matrix, but still... i took the upper 2x2 portion of the matrix and changed to identity matrix, and to my surprise nothing happened, then i took the whole matrix as 3x3 and then converted it to identity matrix and then some changes were imparted. Like the white document windows instead of having '0' pointing to it, although the scale was still increasing in the same direction as earlier but the scaling had increased, we will see as to where to go on next from this event bottom instead had '0' pointing to the upper corner. But i should mention that first I set the _doc2dt calues only in the SP-Desktop class(by doing _doct2dt[0]=1 etc..) , but the 3x3 changes i did, was actually in the Geom:Scale where i changed the Matrix() operator values, so the visual changes appeared. When i restored those changes and did the identity matrix 3x3 thing only in the Sp-Desktop class then again i didn't see any changes. The changes which occurred, I have an idea as to why they popped(the Scale class must be used by other functionalities of codebase and i changed that one). But on changing things in the Sp-Desktop class why no affect was created, I am totally unaware.
So I hope I will get more guidance on it, apart from my own trying(I don't yet know the entire codebase and functionalities of different modules). Waiting for developer's response.
Thank You.
On 03/28/2010 09:58 AM, Abhishek Sharma wrote:
but what i also noticed was that, at implementation level the _doc2dt was not a matrix but an array of size 6 and if logically seen as matrix -> _doc2dt has 3x2 dimensions, so i didn't quite get as to how it can be an identity matrix,
It's an homogeneous matrix, see http://www.blancmange.info/notes/maths/vectors/homo/ for an explanation. The last section titled "computational efficiency" will shed some light on this.
Regards,
Diederik
Sun, 28 Mar 2010 13:28:45 +0530 Abhishek Sharma <spyzer.abhishek0@...400...> kirjoitti:
but what i also noticed was that, at implementation level the _doc2dt was not a matrix but an array of size 6 and if logically seen as matrix -> _doc2dt has 3x2 dimensions, so i didn't quite get as to how it can be an identity matrix, but still...
This is a common trick in 2D graphics. A 3x3 matrix can represent combinations of scaling, rotation, shearing and translating for 2-dimensonal images. However, none of these operations modify the third row of the transformation matrix, so only the first two rows are stored and the third row is assumed to contain (0, 0, 1)
Hi,
So this neat trick actually has to do with translations and efficiency, now I get it. May some one also kindly specify the reason I was suggested to modify the matrix to an identity one. I mean how would changing _doc2dt to an identity matrix help in the bug reduction(I am asking this not to comment or question anybody, I am just unaware...). Besides if developers may also guide me as to what are the other classes which I need to take care of for this bug fixing, like any GUI class which shows the left hand scale, or any core class on which the other classes depends for the co-ordinate system(as of now, that core class seems to be SP-Desktop); then it would be of real help.
Thank You.
On Sun, Mar 28, 2010 at 5:31 PM, Niko Kiirala <niko@...1267...> wrote:
Sun, 28 Mar 2010 13:28:45 +0530 Abhishek Sharma <spyzer.abhishek0@...400...> kirjoitti:
but what i also noticed was that, at implementation level the _doc2dt was not a matrix but an array of size 6 and if logically seen as matrix -> _doc2dt has 3x2 dimensions, so i didn't quite get as to how it can be an identity matrix, but still...
This is a common trick in 2D graphics. A 3x3 matrix can represent combinations of scaling, rotation, shearing and translating for 2-dimensonal images. However, none of these operations modify the third row of the transformation matrix, so only the first two rows are stored and the third row is assumed to contain (0, 0, 1)
-- Niko Kiirala niko@...1267...
Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
2010/3/28 Abhishek Sharma <spyzer.abhishek0@...400...>:
So this neat trick actually has to do with translations and efficiency, now I get it. May some one also kindly specify the reason I was suggested to modify the matrix to an identity one. I mean how would changing _doc2dt to an identity matrix help in the bug reduction(I am asking this not to comment or question anybody, I am just unaware...).
There are two coordinate spaces: the document space, which corresponds to the SVG specification, and the desktop space, which is the same except it has the Y axis flipped, and is used to position items on the canvas. What we want is to change the desktop space to be identical to the desktop space. _doc2dt determines the mapping between the document space and desktop space, so we need to change it to the identity matrix to make those two spaces identical.
Regards, Krzysztof
Thank You for this explanation. As suggested by Krzysztof I changed the matrix to be an identity one, but then why can't I see any changes in the application. I mean nothing is happening by changing it to identity matrix. But as told, _doc2dt represents the mapping of co-ordinates of two spaces, the thing must show change after changing this matrix to an identity one. I can only report that previously this was the matrix(1,0,0,-1,0,document->height) and i changed it to (1,0,0,1,0,document->height); I hope I did it correctly.I did this change just in the local copy of _doc2dt and nothing happened.
2010/3/29 Krzysztof Kosiński <tweenk.pl@...400...>
2010/3/28 Abhishek Sharma <spyzer.abhishek0@...400...>:
So this neat trick actually has to do with translations and efficiency,
now
I get it. May some one also kindly specify the reason I was suggested to modify the matrix to an identity one. I mean how would changing _doc2dt
to
an identity matrix help in the bug reduction(I am asking this not to
comment
or question anybody, I am just unaware...).
There are two coordinate spaces: the document space, which corresponds to the SVG specification, and the desktop space, which is the same except it has the Y axis flipped, and is used to position items on the canvas. What we want is to change the desktop space to be identical to the desktop space. _doc2dt determines the mapping between the document space and desktop space, so we need to change it to the identity matrix to make those two spaces identical.
Regards, Krzysztof
Hello,
With an earlier discussion with Krzysztof we were able to move ahead in the bug fixing. I would be glad to know the next move. Which module of codebase is supposed to be the next target for co-ordinate system mapping changes?? I think gradually, with some help, this bug would be fixed. Till now the promising changes were removing Geom::Scale(1,-1) and the Geom::Translate(0,sp_document_height). Some bizzare changes were reflected for keeping _doct2dt the same. I would be glad to move ahead now...
Thank You.
participants (4)
-
Abhishek Sharma -
Diederik van Lierop -
Krzysztof Kosiński -
Niko Kiirala