User:Vladbogolin/Proposal/DisplayManager

Personal Information

• Name: Bogolin Simion Vlad
• E-mail address: vladbogolin@gmail.com
• IRC username: vladbogo

Background info

I am a third year student at Polytechnic University of Bucharest, studying computer science. The main areas that I am interested in are: algorithms, computer graphics and operating systems.

Project Information

Project Title

New Cross-Platform 3D Display Manager

Brief project summary

Create a new cross-platform 3D display manager. A display manager is the primary means with which BRL-CAD interacts graphically with geometry. Basically the project’s purpose is to implement a new display manager using Qt/OGRE. This should be done as an extension to BRL-CAD's libdm library.

Description

Basic steps

Even though the purpose of this project is to create a new display manager interface, this cannot be done without being careful about all the features that a DM should support in order to maintain previous functionalities. So this is one of the most important things I plan to have in mind while implementing the new DM (for features to be supported see "Features"). After this, I can start working effectively and the next step would be to embed Qt with Tk (for more information see Embed Qt in Tk windows). When all this is done, I can start working on the actual operations that need to be supported. Finally, last step would be testing.

When all done, I can start working on the actual operations that need to be supported. Finally, last step would be testing.

Features

Embed Qt in Tk windows

• Step 1: Open

In order to maintain functionality the new DM should be embedded in Tk windows. To do this it is necessary to make all the initializations of the new display manager that uses Qt but to make it in such a way that can be integrated in Tk. In order words, a new Tk_window should be created and also geometry attributes for the window should be specified. Then, the window must be mapped. Meanwhile, Qt/ogl context must be created. As the window is created and the DM initialized, it is ready to be fired up. This should be one of the first steps that must be implemented.

• Step 2: Init

The initialization of the DM consists on adding an event handler that executes when an event occurs and on defining the behaviour of the dm when a command is executed (a command that involves the dm such as “set”). The initialization step is done when mged attaches the dm.

• Step 3: Open framebuffer

In order to have a functional display manager, a framebuffer needs to be opened in order to be used.

• Important aspects:
  • One of the most important things that should be considered while doing this is the fact that the DM should be cross-platform. As I recently experienced (on my Operating Systems course) this could be quite tricky but I will try to consider all things that might be problematic from the beginning. This will be solved probably using macros for things that need to be different accordingly to a specific OS.
  • Step 2 and 3 are routines specific to MGED’s use of LIBDM.

Basic operations

Drawing

Drawing is one of the most important operations. Without this operation a new display manager would be useless. When it comes to drawing there should be done some several steps in order to actually draw. First step is to initialize the environment for the draw operation (drawBegin), then do the actual drawing and finally flush the output buffer(drawEnd).

Line Drawing

• After doing all the above steps, drawing a line shouldn’t be so difficult. As I saw in the existing code, the line is drawn using each display manager particular way. So this means that drawing a line needs to call the Qt appropriate function with the actual values stored in struct dm.

Text Drawing

• Text drawing should be done in the same way Line Drawing is done. As I researched in Qt a string can be drawn inside a rectangle or from a point.

Testing

In order to make a good project writing code is just not enough so I will highly focus on testing. First of all I plan to do a step by step test, meaning that after every new feature's implementation, I will test it. After the project is implemented (hopefully with at least 2-3 weeks before the deadline) I will focus just on testing.

One of the top features of the display manager is to be cross-platform, so I will test it on multiple platforms. At the moment I have installed two Linux distribution (32 and 64 bits), and also Windows (7 and 8, 64-bits) so testing will be on this three platforms. If, after consulting with my mentor, we decide that there is a particular distribution on which I should test the DM, there would be absolutely no problem testing on it.

Testing will consist mostly in creating and loading different models in the new display manager.

Deliverables

The project can be divided in at least 5 parts, so this can be considered a specific measurable goal. I plan to deliver a patch at the end of each phase. I will primarily work on linux and at the end of each phase I will test the code also on Windows and make the necessary changes.

The first patch should include the integration of Qt in Tk windows. Then, after performing every basic action I will submit another patch as soon as I have a new working feature. Finally, I will test the entire application cross-platform, but I also plan to make lots of test on the way.

Schedule

This is a rough plan that I am I sure I will be able to follow. I hope I would be able to deliver the patches earlier than scheduled. As planned the project should be ready with at least 2 weeks before the final deadline.

• Week 1 (17 June - 24 June): Look even more on the code to see everything that I might have missed during the application period. I plan to look until the official starting date but I do not know if I will have time because this period overlaps with my exams period so I will be busy. If I will consider that everything is understood, I will start working effectively and writing code.

• Week 2-3 (24 June - 8 July): During this time I plan that Qt will be embedded in Tk and submit the first patch. This time includes at least one day for testing.

• Week 4 (8 July - 15 July): This week is reserved on implementing the drawing line functionality. At least at the end of this week the second patch should be delivered.

• Week 5 (15 July - 22 July): This week is reserved on implementing the drawing text functionality. At least at the end of this week the third patch should be delivered.

• Week 6 (22 July - 29 July): Preparing mid-term evaluation

• Week 7 - 9 (29 July - 19 August): Implementing the keyboard and mouse integration between Qt and Tk. A new patch should be submitted.

• Week 10 - 12 (5 August - 9 September): Embedding a framebuffer window. A new patch should be submitted.

• Week 13 - 14 (9 September - 27 September): Final testing and submitting the final application.

Time availability

I can say without any doubt that I can fulfil the minimum required time of 40 hours / week. As I understood after talking with the community this is quite a complex project so if it will be necessary I could work more. This project is really interesting to me so I will invest as much time as it need in order to finalized it.

Known commitments

• Exams: my exam period ends on 14 June so it does not overlap with the official schedule, but I must say that until then I won't be able to start working 100%.

• Vacations: I plan to take about a week of vacation during the summer. Probably there will be some free days after my exams period also. I don't think this is a problem because I plan to take this vacation accordingly to my progress on the project and after consulting with my mentor.