On 21/07/14 17:45, Emil Velikov wrote:
On 17/07/14 05:40, Chad Versace wrote:
Emil,
I'm finished reviewing for today, and am stopping here at patch 16. I'll
resume reviewing tomorrow.
I see that you're collecting reviewed-by tags and cleanups on versioned
brancehs (for-upstream-3.*). I will defer cherry-picking patches off the
mailing list onto master; and instead will wait for you to send merge
requests, because I assume that was your intended workflow. If you want
to do things differently, let me know.
Hi Chad,
I do not mind either way (cherry-picking or sending pull requests), I mostly
work this way to have a form of an incremental build-up based on the feedback
received.
Changes in for-upstream-3.2:
- addressed your initial comments
- dropped patch 10 (add -fPIC for the whole of waffle)
- updated patch 17 (introduce third_party/threads) to build with PIC
- squashed two warnings in the threads library (separate commits so that I
can get them back in mesa)
- cleaned/simplified up the cmocka build to make it possible to make it
buildable in cross-builds and/or windows
A bit more work on separate branches
- cleaned up a few cmocka warnings, sent the fixes upstream - not merged yet
- de-duplicated the platform specific tests in gl_basic_test, having fun with
porting run_testsuite() - fork(), waitpid()... to win32
- moved libEGL from link dependency to dlopen() at runtime - got bored of
reading MS documents
- added basic wgl support for piglit - might not be as straight forward as I
expected, see below for more
Brian, Jose,
Short summary at my next obstacle and my current ideas/possible solutions
piglit, glut and waffle:
1) waffle abstracts windows and gl management and is capable of returning the
native objects (window, ctx...)
2) but does not do any input -> piglit + waffle uses linux (posix/unix?)
specific input code.
1) My present WGL code does not have the *.get_native() hooks. Currently
beating them into shape.
2) AFAICS there are ways to address the input issue
a) rip out the glut completely and write Windows specific code for the input
handling. I have close to zero experience in this area, any suggestions ? What
would happen with other platforms using glut like MacOS ? Is it even possible
to do that today ?
b) rip out the glut GL parts but keep the input code in. Seems slightly messy
and I'm not sure it will even work.
Any ideas/suggestions on point 2 above ?
I think that mixing GLUT with other stuff is a bad idea.
Otherwise -- whether to add some input support to waffle or not -- is a
design choice that Chad needs to make.
On one hand most similar frameworks (GLUT, GLFW) tend to have input too.
One the other hand. For GL testing (piglit/apitrace) probably it
doesn't make much difference either way.
At least for piglit/apitrace input is not really a must: in the "-auto"
input is ignored, and in the non "-auto" mode we could simply put a
Sleep() function instead of a wait-for-key, which would probably be good
enough for most cases. (We could also read input from stdin, which can
be done with portable C)
Last but not least - which approach would be the best for getting the WGL code
integrated upstream ?
1) one big code blob
2) commit one - empty skeleton, two - widows_create, three - window_show...
3) keep the series as is - small and gradual changes
4) other ?
I'm leaning towards the third option, yet we're talking about ~25 commits.
Perhaps the second would be a reasonable compromise ?
Small and gradual changes are indeed nice to review. To commit them as
is or squash is up to Chad -- I'm fine either way.
Jose
_______________________________________________
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
