User:Vladbogolin/Proposal/EmbeddingFrameBuffer

Personal Information

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

Brief background info

I am a fourth year student at "Politehnica" University of Bucharest, Computer Science and Engineering Department. The main areas that I am interested in are: algorithms, computer graphics and operating systems.

My skills consist in a strong background in algorithms and data structures. As it comes to programming languages I prefer C/C++ and Java, in which I also have more experience (about 2 years in Java and more than 6 years with C). Apart C/C++ and Java, I have experienced the next programming languages: Python, Haskell, Scheme, Bash Scripting, Matlab, Assembly language, Clips, Prolog. When it comes to versioning tools, I am quite familiar with Git (I have developed several school team projects using it) and SVN.

Project Information

Project Title

Embedding a framebuffer window

Brief project summary

The purpose of this project is to create a new cross platform Qt framebuffer and embedding a framebuffer window in the actual Qt display manager. I have chosen this project in order to have a fully functional display manager in Qt.

Detailed project description

BRL-CAD displays its raytracing output as it is generated by using a framebuffer. Currently BRL-CAD has specific framebuffers for X11 Opengl (ogl), Windows OpenGL (wgl), and raw X11 (X), in addition to a variety of more special purpose and experimental framebuffers. The project aims to create a new Qt framebuffer that would be fully integrated with mged and archer and also with the actual Qt display manager. Even though embedding a framebuffer window is one of the main purposes of the project this will not interfere in any way with having a completely independent 2D Qt framebuffer.

Framebuffer features

• per-scan-line drawing
• good drawing performance
• keyboard and mouse input

In order to have a completely functional framebuffer the above features should be implemented. During the whole project I will have in mind performance so that the framebuffer could provide a good response time.

Implementation details

• Step 1: Open/Close - Initializing all necessary structures, setting up the state information data such as parent window, colormap, width, height / free all resources
• Step 2: Read/Write to the framebuffer
• Step 3: Read/Write colormap to framebuffer
• Step 4: Flush
• Step 5: Embedding a framebuffer window (overlay, interlay, underlay) is strongly related to raytracing. Actually, in this case there is another BRL-CAD program that mget lunches (rt) that does the actual raytrace. Also a framebuffer refresh is necessary to perform this action. Doing this in Qt should be very similar. When this feature is called, the actual raytrace must be done and the framebuffer used by Qt has to be refreshed.

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 implemented, 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.

Testing will consist in creating and loading different models and raytracing the models to make sure everything works as expected and has a good response time.

Links to any code or algorithms you intend to use

Below can be found some general information links:

• http://en.wikipedia.org/wiki/Framebuffer
• http://en.wikipedia.org/wiki/Ray_tracing_%28graphics%29

but the main resource I am going to use is the actual code from libfb.

Deliverables (specific, measurable goals)

At the end of the project a fully functional Qt display manager (with all required features) should be delivered. In order to achieve this a 2D Qt framebuffer will be implemented.

Development schedule

• Community bonding: discuss with mentors, research, start implementing
• Week 1: opening/closing the framebuffer (fb_open, fb_close)
• Week 2 - 4: implementing the libfb functions/ testing as they are done.
• Week 5: testing to make sure that everything works as expected. Also, preparing for midterm evaluation.
• Week 6 - finishing implementing the libfb functions (at least fb_read, fb_write, fb_flush, fb_poll, fb_rmap, fb_rmap should be implemented at this time)
• Week 7-8: make the display manager use the framebuffer - open the new framebuffer so that the display manager can use it, implement the open_existing function
• Week 8-9: integrate the framebuffer with the rt command so that the raytracing can be done (modify pkg_open and rem_open so that the framebuffer can be used)
• Week 10: testing the embedding of a framebuffer window in the display manager
• Week 11-12: more testing and time for unexpected problems.
• Week 13: final testing and preparing the final evaluation

The above schedule is orientative. I tried making it as realistic as possible and reserved time for unexpected problems that might appear.

Describe time availability (40+ hours/week assumed)

The starting coding period overlaps a bit with my exam period (I will probably have one or two exams in the last weeks of May), but this shouldn’t be an issue: if necessary I will start coding earlier so that everything goes according to schedule. Also, in July I will have my final paper presentation (one or two days). This shouldn't be an inconvenient because I plan to have my final paper done until the coding period starts. Apart from this, I don’t have any other commitments.

Why BRL-CAD?

First off all, I started working with BRL-CAD last year and I really enjoyed the project and the community. I learned a lot of new things, got in touch with amazing people and I want to have the same experience again.

Why me?

I don’t like having work done partially so I would like to add new features to the project I started last year so that it would be fully functional.