Hi,
On Tue, Mar 29, 2011 at 04:32:34PM -0600, Rob Savoye wrote:
Sorry, I see little useful outcome of kicking a flame war into full
force, and you aren't even a Gnash developer anyway, so don't expect any
responses from me. I know this sounds rude, but answering endless
personal attacks is a
Hi,
On Tue, Mar 22, 2011 at 12:12:26PM -0600, Rob Savoye wrote:
It currently only works with the nouveau driver and libMesa.
Why is that? Seems strange, considering that the whole point of Gallium
is making the state trackers (GL, GLES, VG etc.) independent from the
pipe drivers (nouveau,
Hi,
On Tue, Mar 22, 2011 at 10:44:53AM -0600, Rob Savoye wrote:
On 03/22/11 10:34, Sandro Santilli wrote:
What do you want us to look at then ?
Real programmers can read code. :-)
I'm sure Gnash will go down in history -- as the project that failed
because nobody wanted to be a real
Hi,
On Tue, Mar 22, 2011 at 03:46:36PM -0600, Rob Savoye wrote:
Try not to assume I won't fix something just cause you don't think I
will. Review comments about compiler warnings aren't useful, that's what
the compiler is for. Those are the kinds of things I'll be fixing in the
near future
Hi,
On Wed, Mar 23, 2011 at 09:34:28AM -0600, Rob Savoye wrote:
How can you review anything, high level or not without looking at the
code ? I'm not trying to insult you, just how can we discuss something
you haven't even made a fast scan over ? I can answer technical
questions endlessly,
On 03/28/11 07:44, olafbuddenha...@gmx.net wrote:
Sorry, I see little useful outcome of kicking a flame war into full
force, and you aren't even a Gnash developer anyway, so don't expect any
responses from me. I know this sounds rude, but answering endless
personal attacks is a major waste of
On Tue, Mar 22, 2011 at 04:40:38PM -0600, Rob Savoye wrote:
On 03/22/11 16:04, Benjamin Wolsey wrote:
It would help to ensure that it doesn't get forgotten.
I don't forget things on my top of my TODO list... There's a big
difference in our styles, I do things by making several passes
On 03/23/11 03:24, Sandro Santilli wrote:
Problem is that when you're a working in a team, your in steps work
gets in the way of others, which are forced to deal with issues
that prevent them from properly testing/debugging their own code.
The way I work has never gotten in anyone's way in
On Wed, Mar 23, 2011 at 06:50:36AM -0600, Rob Savoye wrote:
What does libdevice do ?
It's a library that deals with hardware devices. :-) In this case
input and output devices.
[...]
This sure would be easier if you actually looked at the code.
I tought you mentioned you wanted
On 03/23/11 09:14, Sandro Santilli wrote:
On Wed, Mar 23, 2011 at 06:50:36AM -0600, Rob Savoye wrote:
I thought you mentioned you wanted high-level reviews, rather than
detailed bug reports.
How can you review anything, high level or not without looking at the
code ? I'm not trying to
On Wed, Mar 23, 2011 at 09:34:28AM -0600, Rob Savoye wrote:
Because now with OpenVG (or GL*) Gnash supports doing gradients in
hardware, something we've never supported before. This required a minor
tweak to the rendering API as to do gradients in hardware as it had to
be done someplace
On 23 Mar 2011, at 16:53, Sandro Santilli wrote:
On Wed, Mar 23, 2011 at 09:34:28AM -0600, Rob Savoye wrote:
Because now with OpenVG (or GL*) Gnash supports doing gradients in
hardware, something we've never supported before. This required a minor
tweak to the rendering API as to do
GtkOvgGlue does not presently work, I think because the following
requirement from the EGL specification is not met:
To create an on-screen rendering surface, first create a native platform
window with attributes corresponding to the desired EGLConfig (e.g. with the
same color depth, with
Now that the release is out, I plan to migrate my 'openvg' branch to
master. While I'd like to migrate this in stages, it may be difficult.
If anyone has concerns about this code, they should review the branch
*now*, and not start another endless flame war after this is merged. As
I won't be
On Tue, Mar 22, 2011 at 08:35:42AM -0600, Rob Savoye wrote:
Now that the release is out, I plan to migrate my 'openvg' branch to
master. While I'd like to migrate this in stages, it may be difficult.
If anyone has concerns about this code, they should review the branch
*now*, and not start
On 03/22/11 08:59, Sandro Santilli wrote:
Reducing the noise would involve merging master into branch carefully
resolving conflicts, and then possibly reducing changes even further
by making sure _every_ change in branch is related to openvg.
Merge changes aren't really an issue for
On Tue, Mar 22, 2011 at 09:07:18AM -0600, Rob Savoye wrote:
I doubt anyone on this list has the proper hardware to actually run
this code anyway till I get the GTK support thoroughly debugged for the
desktop.
What do you want us to look at then ?
Maybe it's more useful if you give an
On 03/22/11 10:34, Sandro Santilli wrote:
What do you want us to look at then ?
Real programmers can read code. :-)
Maybe it's more useful if you give an overview of what changes in terms
of interfaces, so we can give comments on that.
Actually there have been very few interface
On Tue, Mar 22, 2011 at 10:44:53AM -0600, Rob Savoye wrote:
On 03/22/11 10:34, Sandro Santilli wrote:
What do you want us to look at then ?
Real programmers can read code. :-)
Yeah, but Real Hackers are also very lazy :)
Maybe it's more useful if you give an overview of what changes
Actually there have been very few interface changes, more moving code
around and adding piles of new code. The libdevice internal API is new
in it's entirety. I do plan to add more doxygen documentation as I do
the merge, and you'll see the commits in the email list.
I can't currently compile
On 03/22/11 11:48, Sandro Santilli wrote:
I actually see no GLES renderers in master, and 2 of them in openvg
branch: opengles1, opengles2. Are them in any way related to the
openvg one or completely standalone ?
GLES1 and GLES2 unfortunately have differing APIs. GLES1 is based on a
patch I
On 03/22/11 11:51, Benjamin Wolsey wrote:
I can't currently compile this code because I don't have openvg on my
machines.
Currently OpenVG is available on Ubuntu Maverick or Natty. I'll be
working on the GTK-OpenVG glue this week, which you would need to
actually test it on your desktop. It
On Tue, 22 Mar 2011, Rob Savoye wrote:
Like I mentioned, libdevice and gui/fb are the main changes other than
the OpenVG renderer itself.
Wouldn't you have to merge master into your branch anyway prior to
merging your branch into master? So if you do that now, it'll be easier
for people to
On 03/22/11 13:02, Bastiaan Jacques wrote:
Wouldn't you have to merge master into your branch anyway prior to
merging your branch into master? So if you do that now, it'll be easier
for people to see the changes you want to make, which would lead to
better feedback and easier bugfixing (and
On Tue, Mar 22, 2011 at 12:12:26PM -0600, Rob Savoye wrote:
On 03/22/11 11:51, Benjamin Wolsey wrote:
If the old
functions are to be replaced, code in the existing three renderers needs
to be adapted to the new accessor and the old accessors removed.
I didn't adapt the existing
On 03/22/11 15:16, Sandro Santilli wrote:
Does this mean you think the old functions are to be replaced ?
Is it really necessary ? Can you give more details on the issue ?
It's not necessary, but as bwy pointed out, there currently there is
some duplication of accessors that work slightly
On Tue, Mar 22, 2011 at 03:24:42PM -0600, Rob Savoye wrote:
On 03/22/11 15:16, Sandro Santilli wrote:
Does this mean you think the old functions are to be replaced ?
Is it really necessary ? Can you give more details on the issue ?
It's not necessary, but as bwy pointed out, there
On 03/22/11 15:38, Sandro Santilli wrote:
Wouldn't it be easier and safer just to change the _new_ code to use the
_existing_ accessors ? It probably helps reducing bugs if changes in
interfaces are avoided as much as possible.
Changing working code seemed more unstable than leaving it
Changing working code seemed more unstable than leaving it alone
during the merge phase. While I could look at fixing that now, like I
keep having to say, I planned to do that as a followup phase after the
merge. I don't see any real reason why it has to be now. Real soon is
good enough for
On 03/22/11 16:04, Benjamin Wolsey wrote:
It would help to ensure that it doesn't get forgotten.
I don't forget things on my top of my TODO list... There's a big
difference in our styles, I do things by making several passes over
them, you seem to prefer things to be more complete. I don't
30 matches
Mail list logo
