[Bf-committers] Weekly Blender developer meeting minutes - December 29, 2013

Sat Jan 4 15:51:20 CET 2014

@Arnaud,

Sorry about all this mess with missing files. I'm new to git and github,
and this is the first time I'm using these tools. I'm reading some
materials like http://nvie.com/posts/a-successful-git-branching-model/ to
know how to work better with the repo.

Your makefile lacks the compilation of GUI_draw:
gcc ... GUI_draw.o -c GUI_draw.c ...

Your makefile looks better than mine, let me just learn how to merge
individual files :), then I'll merge it into the repo.

glScissor is just an mask peration, at least it seems to be. If I knew
about it at first, I would never used FBOs for this project in the
beginning.

I compile BasicUtils as static in a system directory just because it is a
library that I'm using for more 2 projects. And I'm used to see the
libraries of others developers as static and in a system wide dir, too.
But, I'm not inflexible about it, I may include the library in the TableGUI
folder =).

Regards,
Felipe

2014/1/4 Arnaud Loonstra <arnaud at sphaero.org>

> Hi Felipe,
>
> I was just fixing the Makefile and was able to build the lib when you
> commited just an hour ago. It now errors on:
> GUI.c:428: undefined reference to `GetIntersection'
>
> ... and some more.
>
> The cleaned up of the Makefile:
> https://github.com/sphaero/TableGUI/blob/master/Makefile
>
> However I can't compile now because of above errors. I can do a pull
> request for the Makefile but I'd rather wait for the above errors to go
> away first. I think I'm missing some file again ;) Make sure you check
> 'git status' before doing pushes.
>
> The BasicUtils lib puzzles me a bit since you compile it as a static
> lib. As a static lib it not really usefull installed system wide. It
> should probably be a shared lib or just included in TableGUI?
>
> The glScissor thing sounds really great. I'm not familiar with it other
> than that is used the determine a mask for updating?
>
> About the application loop. I know in most GL apps the loop is usually
> done at Xfps however for an UI lib it could be a bit overkill. If
> nothing happens a loop can just wait for an event and do nothing in the
> meantime. But I'm still thinking this through how this works with GL. In
> Blender I think the UI is drawn every 30 frames or so...
>
> Rg,
>
> Arnaud
>
> On 01/03/2014 10:10 PM, Felipe Ferreira da Silva wrote:
> > I'm considering make a blog about the gui toolkit, write about the
> > progress, post concepts and ideas, and receive opinions.
> >
> > @Hi, Arnaud.
> >
> > Thanks for the warning. I've never used git and github before, so I
> > end up forgetting
> > to include some files before commit. I'm compiling it on Archlinux.
> > You will need:
> > BasicUtils (another library mine, also on github) and
> > Cairo library (used only to create the font texture).
> >
> > I will try to compile under windows later.
> >
> > Here is the current main loop inside GUI.c: http://pastebin.com/dnFR7U4X
> > It is not the same at the github (name as "RunWindow"), this one was not
> > commited yet.
> > I'm not using sleep to force the rendering frame-rate, since it would
> stop
> > the "processing" frame-rate too. I'm just subtracting the last time by
> the
> > current time, if the value is > than 1 sec, then the rendering function
> is
> > called. It resembles the "Constant Game Speed with Maximum FPS" loop at
> > http://www.koonsolo.com/news/dewitters-gameloop/.
> > The SDL calls are commented and being replaced by GLFW/OpenGL calls.
> >
> > So, since my last message, I switched from FBOs to use glScissor
> instead. I
> > could not ask for better results, performance is not a problem anymore:
> >
> > When I was using FBOs
> > * Using < 400 widgets, the processing frame-rate was about 420000 cycles.
> > * The rendering frame-rate was at the max speed: 60 fps.
> > * But the processing frame-rate can decreases very fast, an > 400
> widgets,
> > the rendering frame-rate was comprimised.
> >
> > Using glScissor
> > * I was able to use more than 3600 widgets and keep the processing
> > frame-rate about 530000 cycles!!! The top frame-rate is about 850000
> cycles.
> > * Virtually, no lost of rendering frame-rate.
> >
> > About the current state of the widgets, I have:
> > Single-line editor (short name: Entry).
> > Tabset (cool feature: to scroll the tabset, you have to hold righ-click
> and
> > move the cursor).
> > Notebook.
> > Label.
> > Treeview (still WIP).
> > Scrollbar (need some polish).
> > Button.
> > I just made a commit, but I will commit again soon (today, or tomorrow).
> >
> > I've changed some stuff that affects how to integrate the toolkit with a
> > script language, but I will write about it later.
> >
> > Regards,
> > Felipe Ferreira
> [snip]
>
>
> --
> Stichting z25.org
> Concordiastraat 67A
> 3551 EM Utrecht
> The Netherlands
>
> m: +31-(0)6-41861063
> e: arnaud at z25.org
> w: http://z25.org
> t: http://twitter.com/z25org
> f: http://fb.com/z25org
> g: http://gplus.to/z25
> l: http://linkedin.com/company/z25
>
> --
> w: http://www.sphaero.org
> t: http://twitter.com/sphaero
> g: http://github.com/sphaero
> i: freenode: sphaero_z25
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>

-- 
- Felipe Ferreira da Silva