Bug 86190 - use GLM library instead of basegfx
Summary: use GLM library instead of basegfx
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: Other All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-11-12 08:02 UTC by Michael Jaumann
Modified: 2020-03-02 13:01 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Jaumann 2014-11-12 08:02:47 UTC
In order to improve stability, we need to change basegfx to GLM.

The basegfx module (http://opengrok.libreoffice.org/xref/core/basegfx/source/) implements basic algorithms and datatypes for graphics. 

GLM provides some additional functionality and could be used in OpenGL too. 

So you have to overload the methods in basegfx to return glm datatypes.
The second part of the task, would be writing wrappers between glm and basegfx datatypes.

Thanks!
Comment 1 Michael Stahl (allotropia) 2015-04-11 16:55:42 UTC
idly wondering why we have to start with basegfx, aren't there much uglier things in tools like Rectangle, Polygon etc. to replace :)
Comment 2 Markus Mohrhard 2015-04-13 19:43:16 UTC
glm provides a well maintained library for low-level computer graphics algorithms that maps really well to OpenGL.

Of course this does not mean that an easy-hack for replacing tools classes would not be a good idea. However this one is a task related to our other OpenGL tasks.
Comment 3 Zsolt Bölöny 2015-05-16 15:16:58 UTC
I'm interested in this, as I have some experiences with GLM, but the task is not completely clear to me.

What methods should I overload to return GLM datatypes? Basegfx mostly contains classes which are used widespread in the codebase. There are two things I can think of: 1) keep the current classes and use them as a wrapper around the corresponding GLM types (e.g. use a glm::dvec2 instead of two doubles in B2DVector), or 2) completely get rid of basegfx's vectors and matrices, find out where they're used, replace them with GLM ones and put the additional helper methods (like matrix inversion, etc.) into new class(es).

The first scenario is this easy-hack is about, I think (plus the writing of conversion functions between basegfx and GLM types).

Please somebody confirm what I think is correct, so I can start hacking.
Comment 4 Robinson Tryon (qubit) 2015-12-10 11:40:52 UTC Comment hidden (obsolete)
Comment 5 Robinson Tryon (qubit) 2016-02-18 14:52:31 UTC Comment hidden (obsolete)
Comment 6 Thorsten Behrens (allotropia) 2020-02-12 22:03:59 UTC
Not as clearly defined as we would expect these days
Comment 7 Noel Grandin 2020-03-02 13:01:25 UTC
Closing this as wontfix since none of the active developers has shown any interest.

Please re-open if someone feels like actually working on this.