Skip to content
This repository has been archived by the owner on Mar 29, 2024. It is now read-only.

synchronize release binaries & announcements #35

Closed
azrdev opened this issue Feb 15, 2018 · 1 comment
Closed

synchronize release binaries & announcements #35

azrdev opened this issue Feb 15, 2018 · 1 comment

Comments

@azrdev
Copy link

azrdev commented Feb 15, 2018

In https://sourceforge.net/p/auber/feature-requests/154/ I was told current binary releases were built with Qt5. When checking this, I noticed the builds on github differ from those on sourceforge:
github has separate 32 and 64bit builds and different python versions, whereas sourceforge does not tell about the bitness nor the included python version, but provides a download without python.
Looking at Qt versions: Sourceforge windows releases (at least tulip-5.1.0_x64_setup.exe and tulip-5.1.0_x64_no_python_setup.exe) are built with the obsolete Qt4, from github I get a tulip-5.1.0_x64_python36_setup.exe built with Qt5.

I think this situation warrants improvement:

  1. Name the files according to their contents, i.e. bitness, Qt version, python version
  2. Serve the same binaries from both sources, and/or get rid of one (sourceforge, probably) entirely
    • Currently it is not clear which download source should be used, the old website references sourceforge, as does the text of the github release, while in above issue on sourceforge I was told "Tulip development is now hosted on GitHub", and as explained for Qt5 builds I have to go to github
  3. Eventually we should drop Qt4 and python2 (and maybe 32bit too) because they are superseded and not developed anymore. That many different tulip builds also have a higher potential for bugs found in one version, but not the other
@p-mary
Copy link
Contributor

p-mary commented Jun 27, 2019

All Tulip downloadable binaries are now built with Qt5, and they are hosted on SourceForge.

@p-mary p-mary closed this as completed Jun 27, 2019
p-mary referenced this issue in anlambert/talipot Jan 3, 2020
QOpenGL module is marked as deprecated since a while now so it is time
to remove its use from the Talipot codebase and promote the use of
QOpenGL* classes directly integrated in the QtGui module.

The big difference between QOpenGL and QtOpenGL from Qt5 is that all
rendering is performed in framebuffer objects, there is no more direct
rendering in the underlying os windows with its own OpenGL context.

Talipot OpenGL rendering also follows that idiom, all renderings are performed
offscreen using a shared OpenGL context. This also means that there is no
more QGLWidget as viewport for QGraphicsView. Talipot OpenGL scene are
now converted to QImage in order to display them using the default Qt raster
rendering engine. This should fixes the numerous rendering glitches observed
on MacOS.

First thing observed after the migration is a consequent performance boost
in OpenGL rendering when using an Intel GPU on a Linux host machine (especially
when selecting elements, it is now 10 times faster on debian stable).
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants