Est: 4 hours
Wish: Visualization / webgl

Est: 2 hours
Wish: Webpage

Est: 8 hours
Wish: Upload tool

Het lijkt erop dat de screenshot functionaliteit niet werkt als de content door OpenGL is gerenderd. Het resultaat is simpelweg een transparante afbeelding met de grootte van het canvas element.

Het ziet er naar uit dat het ook simpel op te lossen is: https://stackoverflow.com/questions/31710748/todataurl-of-webgl-canvas-returning-transparent-image

Het ziet er naar uit dat dit het gedeeltelijk oplost, echter de achtergrond kleur word niet mee opgeslagen.

Est: 4 hours

Est: 2 hours
Wish: Webpage

Est: 1 hour
Wish: Design

Based on some discussion between @RoanH and me, we figured it might be a good idea for now to have a 'default visualization' which demoes the functionality of the openGL draw methods. This way it stays modular and we can prevent merge conflicts on that.

Est: 4 hours

Dit is een probleem dat gerelateerd overkoepelend lijkt te zijn voor zowel #22 (PR voor de GL test) van @RoanH als de nog oudere PR die al gemerged is met master. Namelijk dat het canvas zijn eerste redraw() niet daadwerkelijk laat zien.

Een browser resize triggered een daadwerkelijke refresh waarbij het canvas correct haar content toont.

In #42 subTreeSize functionality was added. However, for certain data sets in the future it might also be useful if every node can have a specified size other than 1. For example when visualizing file sizes of a file/folder hierarchy.

Est: 4 hours

Est: 4 hours
Wish: Data processing

Est: 4 hours

Est: 4 hours
Wish: Visualization / webgl

Est: 4 hours

Currently the file upload tool only accepts files when the first line is equal to newick;, however not all newick files start with line[1]. Thus potentially some newick files would not work with our upload tool while they should.

[1] https://online.phyloviz.net/data/newick_example_phyloviz.nwk

Est: 2 hours
Wish: Webpage

Currently the web page does not work on most screen sizes other than a fairly high resolution, somewhat wide aspect ratio window. This is evident when using a device in "portrait" orientation. Most styling elements are (fairly) fixed size and are not relative to screen size, including our visualization canvas.

To be clear I believe this is very low priority, however I do think it warrants a mention for potential future feature.

Example screenshots:
https://i.imgur.com/wrO0lNT.png
https://i.imgur.com/BXu408z.png

Zie #4, waarschijnlijk irrelevant maar moeten we maar even naar kijken tegen het eind van het project.

Implement the generalized pythagoras tree based on data gathered from the uploaded file.

Est: 1 hour
Wish: Design

Will be added in #66

Introduction

I'm opening this issue to give a more thorough overview of a recent bug that has been encountered, but unlike in #23 , this is something I feel we should address as it is not a 'possible feature' but a genuine bug.

Images

Below a couple of images in different pieces of software, giving insight into what is going on.

Tree in the viewport

Possible fix

As there are values on the pixels where they should be, but just the representation is inconsitent across applications and always wrong, ánd the correct color appears at the edges (probably due to anti-aliasing), I strongly suspect this to be an encoding issue.

One thing to perhaps consider is that, unlike many image-formats (such as EXR, RAW, TIF) which use an RGBA format, PNG uses RGB and transparency. Transparency != alpha.

I haven't looked at this further, but perhaps this is an angle to approach this from.

Wellicht dat het canvas dan nog 0 x 0 heeft als size? Ben er niet ingedoken, maar de eerste png die ik export via die knop is consistent niet te openen.

The implementation as it is work perfectly fine. However it is possible to make some significant optimalisations.

High level overview

• Reimplement colors
• Refactor arrays
• Ignore vertices outside of the viewport
• Ignore vertices smaller than half a pixel
• Precompute Matrices
• Remove depth
• Remove alpha
• Write shape optimized shaders
• Optimize the rendering pipeline

Shapes that are functionally done

Branch: opengl/optimalisation

• Filled Rotated Quad
• Drawn Rotated Quad
• Lined Rotated Quad
• Filled AA Quad
• Drawn AA Quad
• Lined AA Quad
• Filled Ellipsoid
• Drawn Ellipsoid
• Lined Ellipsoid
• Filled Circle
• Drawn Circle
• Lined Circle
• Ellipsoidal Arc
• Circular Arc
• Line
• Poly Line
• Filled Ring Slice
• Drawn Ring Slice
• Lined Ring Slice
• Filled Circle Slice
• Drawn Circle Slice
• Lined Circle Slice

The data displayed in the tree navigator is always based on the last file that was uploaded rather than the visualization that is currently being shown. Switching tabs the user can potentially see different visualizations of different data while the tree navigator on the right never updates.

I propose one of the following solutions, but I'm always curious for feedback.

• Link the tabs to a data set such that upon opening a tab a data set gets locked in to that tab and switching to a different tab the user gets to see the data associated to that tab (potentially the same if the user did not upload new data in between switching two tabs. (The difficulty with this one is what do you do when the user uploads new data? Perhaps we should not update the tree either until a new tab is created instead of on upload)
• Make it so that all the tabs always show the same, latest data visualized and that the tabs only serve to switch between different visualizations of the same data. (I don't like this idea)

There are many more solutions, but they are intertwined with other design elements of our UI/UX. Thus I propose that we discuss this the next time we meet in person to think this out more thoroughly.

Screenshot: https://i.imgur.com/iMfTF2j.png
Note that the visualization on the left is obviously broken, but it resembles ((A,B),(C,D)) while the tree on the right resembles something much larger.

Est: 4 hours
Wish: Visualization / webgl

Introduction

In multiple visualizations we will have to deal with color and or color-gradients. It would be usefull if we could create a module which implements this in a consistent way.

Suggestion

The creation of a Color module with the following methods and properties:

• [property] x / r / red
• [property] y / g / green
• [property] z / b / blue
• [property] a / alpha
• [property] rgb
• [property] rgba
• randomRGB
• randomRGBA
• gradient2D
• ...

Conclusion

Feel free to update this list and/or discuss.

Est: 4 hours

Add comments later because I'm lazy and in the future some changes need to be made anyway.

As mentioned in #63

Currently the OpenGL context stays alive after closing or reloading the website until the maximum context count of 16 is reached. Therefore memory is not released.