Re: [brlcad-devel] Problem in drop-down and raytracing

Wed, 30 Oct 2013 11:02:24 -0700


On Oct 30, 2013, at 12:46 PM, Deepak Sharma <[email protected]> wrote:

On Mon, Oct 28, 2013 at 2:29 AM, Tom Browder <[email protected]> wrote:
Essentially the same problem I believe--essentially there is no window refresh.
 
The problem is actually that the framebuffer device is unaware of the change in dimensions.  So while the 2D context has been resized by resizing the window, the data structure holding the pixel data is not aware of the change.

As Sean mentioned, that is a known problem and one that has not yet
been addressed (as Sean often says, "patches welcome!"). And I don't
think it has been fixed on the current trunk. I have used BRL-CAD for
many years and am used to the behavior. I normally use a separate
frame buffer and don't worry about re-sizing.

Is it possible to solve this problem?

Of course, anything is possible.  It's just code.  :) 

Nominally the fix is probably to decouple the window/display size from the framebuffer data size, keeping track of both separately.  Not complicated, but it's some work that would take a few days to get right.

Will solving this problem be
beneficial for the future or not? If yes, then I would like to work
out on it and will try my best to solve it. If you agree, will you
please provide me with the initials so that I can work on it in a
better way.

While I would say the embedded framebuffer isn't strictly necessary (some CAD programs don't even provide that option), you'll encounter the same problem if you render into a stand-alone framebuffer window (e.g., run "rt" on the mged command line, try to resize the window).  So yes, it would be beneficial to work on this.

To get started, I suggest working with a VERY basic setup because this will quickly get complicated.  Learn how to render geometry from outside of mged:

$ mged -c test.g make sph
$ rt test.g sph

That should pop up a framebuffer window with a rendered sphere in it.  From there, you can follow the sources.  The rt sources are in src/rt and the framebuffer library it calls into is in the src/libfb directory of a source checkout.
 
I'm having this problem, shall I report bug for this with this specification?

I'm afraid that simply isn't enough information to do anything about it without outright guessing.  There are far too many variables and, as you noted, you're apparently the only one encountering the problem.  It could be something in X11 or Tk or OpenGL or our code or your driver or .. too much.  So your environment IS the environment that would need to inspect the issue.  You could attempt to debug the issue yourself on your system.

A fix cannot be devised without knowing the cause.  You do not know the cause.  I do not know the cause.  If you minimize the window and restore it, does the issue persist?  If the embedded framebuffer is enabled/disabled, does it make a difference?  My suggestion is that you figure out exactly under what, if any, conditions on your system it does NOT occur, and then try to understand the difference.

Cheers!
Sean

------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
BRL-CAD Developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Reply via email to