[vtk-developers] Use (`new') GLEW in VTK?

[Marcus D. Hanwell]

On Mon, Jan 24, 2011 at 4:17 PM, tom fogal <tfogal at sci.utah.edu> wrote:
> "Marcus D. Hanwell" <marcus.hanwell at kitware.com> writes:
>> On Mon, Jan 24, 2011 at 3:47 PM, tom fogal <tfogal at sci.utah.edu> wrote:
>> > David Partyka <david.partyka at kitware.com> writes:
>> >> This looks like a very cool contribution! To get this moving
>> >> forward I am in the process of setting up some dashboards that
>> >> will build your VTK fork so we can see how the tests do on a few
>> >> platforms. One of us will also contact you about code review and
>> >> how to best get this integrated.
>> >
>> > I had been caught up in deadlines but should slowly gain some
>> > time to finish up + correct this code over the next couple
>> > weeks. =A0I still consider it incomplete... but I'm curious about
>> > the status. =A0Has this dashboard been set up? =A0What problems has
>> > it uncovered / how can I view them?
>>
>> It would be nice to create a clean topic branch with these changes,
>> and upload it to Gerrit for code review too. This is something I
>> could help with.
>
> Thanks.
>
> How socially-public are said branches?  (Could I still rebase with
> impunity?)

With Gerrit you get public commits, that can depend on one another. If
you rebase, or fix up commits using rebase -i they show up as further
patch sets in the same proposed commit. It allows for line-by-line
comments, or overall code review/checkout. Rebasing is actually the
preferred way of responding to comments in Gerrit at present.
>
>> We would like to assess any API changes that this move would
>> introduce, and document them. I think this is largely removal of the
>> vtkgl namespace if I remember correctly?
>
> Yes, that's the major change.
>
> An open question is what to do about vtkMesa*.  I initially just left
> them in, but a friend had issues building and so they now sit idly in
> my tree, removed from CMakeLists.txt.
>
> Were/are users allowed to use those classes directly?  If they were,
> I should probably code up some stub classes so that VTK's interface
> doesn't change.

I am not sure, I think this was a factory pattern depending on how VTK
had been built. Other things we would need to look at is how ParaView
is affected, as it makes heavy use of Mesa and offscreen rendering in
clusters that lack GPUs.

Marcus