We'll use OpenGL, the API Mac OS X does natively use. Below the technical description, the involved code, the plan, and so on. Feel free to add information if you estimate it usefull for the task. Thanks in advance:-) Goal. Make OpenGL transitions work in Impress, on Mac OS X Aqua (on both PowerPC and Intel architectures) Timeline. OpenGL Extensions Viewer displays the vendor name, the version implemented, the renderer name and the extensions of the current OpenGL 3D accelerator. Download opengl driver for mac for free. System Tools downloads - opengl by Apple Inc. And many more programs are available for instant and free download. Earlier this month, Apple's developer documentation advised that active development has ceased for OpenGL and OpenCL on the Mac, and that the APIs will only get 'minor changes' going forward.

1. Opengl For Mac Os 10.13
2. Install Opengl On Mac
3. Opengl Mac Os X Download
4. Opengl For Mac Os X
5. Opengl Osx

An eGPU can give your Mac additional graphics performance for professional apps, 3D gaming, VR content creation, and more.

eGPUs are supported by any Thunderbolt 3-equipped Mac¹ running macOS High Sierra 10.13.4 or later. Learn how to update the software on your Mac.

An eGPU lets you do all this on your Mac:

• Accelerate apps that use Metal, OpenGL, and OpenCL
• Connect additional external monitors and displays
• Use virtual reality headsets plugged into the eGPU
• Charge your MacBook Pro while using the eGPU
• Use an eGPU with your MacBook Pro while its built-in display is closed
• Connect an eGPU while a user is logged in
• Connect more than one eGPU using the multiple Thunderbolt 3 (USB-C) ports on your Mac²
• Use the menu bar item to safely disconnect the eGPU
• View the activity levels of built-in and external GPUs (Open Activity Monitor, then choose Window > GPU History.)

eGPU support in apps

eGPU support in macOS High Sierra 10.13.4 and later is designed to accelerate Metal, OpenGL, and OpenCL apps that benefit from a powerful eGPU. Not all apps support eGPU acceleration; check with the app's developer to learn more.³

In general, an eGPU can accelerate performance in these types of apps:

• Pro apps designed to utilize multiple GPUs
• 3D games, when an external monitor is attached directly to the eGPU
• VR apps, when the VR headset is attached directly to the eGPU
• Pro apps and 3D games that accelerate the built-in display of iMac, iMac Pro, MacBook Air, and MacBook Pro (This capability must be enabled by the app's developer.)

You can configure applications to use an eGPU with one of the following methods.

Use the Prefer External GPU option

Starting with macOS Mojave 10.14, you can turn on Prefer External GPU in a specific app's Get Info panel in the Finder. This option lets the eGPU accelerate apps on any display connected to the Mac—including displays built in to iMac, iMac Pro, MacBook Air, and MacBook Pro:

1. Quit the app if it's open.
2. Select the app in the Finder. Most apps are in your Applications folder. If you open the app from an alias or launcher, Control-click the app's icon and choose Show Original from the pop-up menu. Then select the original app.
3. Press Command-I to show the app's info window.
4. Select the checkbox next to Prefer External GPU.
   
5. Open the app to use it with the eGPU.

You won't see this option if an eGPU isn't connected, if your Mac isn't running macOS Mojave or later, or if the app self-manages its GPU selection. Some apps, such as Final Cut Pro, directly choose which graphics processors are used and will ignore the Prefer External GPU checkbox.

Set an external eGPU-connected display as the primary display

If you have an external display connected to your eGPU, you can choose it as the primary display for all apps. Since apps default to the GPU associated with the primary display, this option works with a variety of apps:

1. Quit any open apps that you want the eGPU to accelerate on the primary display.
2. Choose Apple menu  > System Preferences. Select Displays, then select the Arrangement tab.
3. Drag the white menu bar to the box that represents the display that's attached to the eGPU.
4. Open the apps that you want to use with the eGPU.

If you disconnect the eGPU, your Mac defaults back to the internal graphics processors that drives the built-in display. When the eGPU is re-attached, it automatically sets the external display as the primary display.

About macOS GPU drivers

Mac hardware and GPU software drivers have always been deeply integrated into the system. This design fuels the visually rich and graphical macOS experience as well as many deeper platform compute and graphics features. These include accelerating the user interface, providing support for advanced display features, rendering 3D graphics for pro software and games, processing photos and videos, driving powerful GPU compute features, and accelerating machine learning tasks. This deep integration also enables optimal battery life while providing for greater system performance and stability.

Apple develops, integrates, and supports macOS GPU drivers to ensure there are consistent GPU capabilities across all Mac products, including rich APIs like Metal, Core Animation, Core Image, and Core ML. In order to deliver the best possible customer experience, GPU drivers need to be engineered, integrated, tested, and delivered with each version of macOS. Aftermarket GPU drivers delivered by third parties are not compatible with macOS.

The GPU drivers delivered with macOS are also designed to enable a high quality, high performance experience when using an eGPU, as described in the list of recommended eGPU chassis and graphics card configurations below. Because of this deep system integration, only graphics cards that use the same GPU architecture as those built into Mac products are supported in macOS.

Supported eGPU configurations

It's important to use an eGPU with a recommended graphics card and Thunderbolt 3 chassis. If you use an eGPU to also charge your MacBook Pro, the eGPU's chassis needs to provide enough power to run the graphics card and charge the computer. Check with the manufacturer of the chassis to find out if it provides enough power for your MacBook Pro.

Recommended graphics cards, along with chassis that can power them sufficiently, are listed below.

Thunderbolt 3 all-in-one eGPU products

These products contain a powerful built-in GPU and supply sufficient power to charge your MacBook Pro.

Recommended Thunderbolt 3 all-in-one eGPUs:

• Blackmagic eGPU and Blackmagic eGPU Pro⁴
• Gigabyte RX 580 Gaming Box⁴
• Sonnet Radeon RX 570 eGFX Breakaway Puck
• Sonnet Radeon RX 560 eGFX Breakaway Puck⁵

AMD Radeon RX 470, RX 480, RX 570, RX 580, and Radeon Pro WX 7100

These graphics cards are based on the AMD Polaris architecture. Recommended graphics cards include the Sapphire Pulse series and the AMD WX series.

Recommended Thunderbolt 3 chassis for these graphics cards:

• OWC Mercury Helios FX⁴
• PowerColor Devil Box
• Sapphire Gear Box
• Sonnet eGFX Breakaway Box 350W
• Sonnet eGFX Breakaway Box 550W⁴
• Sonnet eGFX Breakaway Box 650W⁴
• Razer Core X⁴
• PowerColor Game Station⁴
• HP Omen⁴
• Akitio Node⁶

AMD Radeon RX Vega 56

These graphics cards are based on the AMD Vega 56 architecture. Recommended graphics cards include the Sapphire Vega 56.

Recommended Thunderbolt 3 chassis for these graphics cards:

• OWC Mercury Helios FX⁴
• PowerColor Devil Box
• Sonnet eGFX Breakaway Box 550W⁴
• Sonnet eGFX Breakaway Box 650W⁴
• Razer Core X⁴
• PowerColor Game Station⁴

AMD Radeon RX Vega 64, Vega Frontier Edition Air, and Radeon Pro WX 9100

These graphics cards are based on the AMD Vega 64 architecture. Recommended graphics cards include the Sapphire Vega 64, AMD Frontier Edition air-cooled, and AMD Radeon Pro WX 9100.

Recommended Thunderbolt 3 chassis for these graphics cards:

• Sonnet eGFX Breakaway Box 650W⁴
• Razer Core X⁴

AMD Radeon RX 5700, 5700 XT, and 5700 XT 50th Anniversary

If you've installed macOS Catalina 10.15.1 or later, you can use these graphics cards that are based on the AMD Navi RDNA architecture. Recommended graphics cards include the AMD Radeon RX 5700, AMD Radeon RX 5700 XT, and AMD Radeon RX 5700 XT 50th Anniversary.

Recommended Thunderbolt 3 chassis for these graphics cards:

• Sonnet eGFX Breakaway Box 650W⁴
• Razer Core X⁴

Learn more

• Learn how to choose your GPU in Final Cut Pro X 10.4.7 or later.
• To ensure the best eGPU performance, use the Thunderbolt 3 cable that came with your eGPU or an Apple Thunderbolt 3 (USB-C) cable. Also make sure that the cable is connected directly to a Thunderbolt 3 port on your Mac, not daisy-chained through another Thunderbolt device or hub.
• If you have questions about Thunderbolt 3 chassis or graphics cards, or about third-party app support and compatibility, contact the hardware or software provider.
• Software developers can learn more about programming their apps to take advantage of macOS eGPU support.

1. If you have a Mac mini (2018) with FileVault turned on, make sure to connect your primary display directly to Mac mini during startup. After you log in and see the macOS Desktop, you can unplug the display from Mac mini and connect it to your eGPU.

2. If you're using a 13-inch MacBook Pro from 2016 or 2017, always plug eGPUs and other high-performance devices into the left-hand ports for maximum data throughput.

3. macOS High Sierra 10.13.4 and later don't support eGPUs in Windows using Boot Camp or when your Mac is in macOS Recovery or installing system updates.

4. These chassis provide at least 85 watts of charging power, making them ideal for use with 15-inch MacBook Pro models.

5. Playback of HDCP-protected content from iTunes and some streaming services is not supported on displays attached to Radeon 560-based eGPUs. You can play this content on the built-in display on MacBook Pro, MacBook Air, and iMac.

6. If you use Akitio Node with a Mac notebook, you might need to connect your Mac to its power adapter to ensure proper charging.

• 1OpenGL transitions on Mac OS X
• 2Modifications
  • 2.2Concerned files / ideas

OpenGL transitions on Mac OS X

Description

In Impress, there are transitions between slides, with or without funny 3D effects. The problem is, those nice and Funny effects are power consuming, and without hardware acceleration – means software rendered –, extremely slow, what is not acceptable by users.

This task aims to replace the software rendered transitions with hardware accelerated transitions on Mac OS X.

We'll use OpenGL, the API Mac OS X does natively use

Below the technical description, the involved code, the plan, and so on. Feel free to add information if you estimate it usefull for the task.

Thanks in advance :-)

Goal

Make OpenGL transitions work in Impress, on Mac OS X Aqua (on both PowerPC and Intel architectures)

Timeline

Expected timeline for the cws to be ready for QA : October / November 2008 May 2009

Child Workspace history

Current status

29th March 2009

• [fixed] The flicker is fixed
• [fixed] All reported issues are fixed on IZ
• [fixed] Build fixed on Leopard
• [fixed] Canvas area returns NULL: in some cases aCanvasArea.X or aCanvasArea.Y returns 0 as size ( was causing a crash)
• [fixed] libcairo space color is now correct (thanks to Thorsten Behrens)
• [FIXME] for some transitions between slide A (first) and slide B (final), there is a ghost of the final B slide at the begining of the transition
• [FIXME] Persistance of the last slide : the 'click to finish the presentation' no longer appears

10th March 2009

• The OpenGL transitions work again.
• The ogltrans4mac child workspace builds ok on Tiger, but needs a patch (build broken in DEV300_m42 helpcontent2, masterfixed in DEV300_m43 )
• [FIXME] Build broken on Leopard, due to bad conversion (the API changed)
• [FIXME] Known issue : the flicker is now at the beginning of the transition :/
• [FIXME] canvas area returns NULL. Probably a bad adaptation of the Linux code. Will have a look

9th March 2009

• work in progress : pixel shaders integration (debugging ... )
• build is now ok
• files 3 new issues
  • fix boost when slideshow is build with debug enabled (missing headers)
  • implement (basic pixel shaders)
  • adapt the new tree, and remove old stuff

8th March 2009

• transogl03 (integrated in DEV300_m42 ) has been integrated. Everything is broken, and needs to be evaluated.
• new subdir scheme, where major OS's will be separated :

• ogltrans4mac has been rebased with DEV300_m42

18th January 2009

• catching with color space issue ...
• build m39 + the new pen + cairo. Found color space and bad views areas issues with cairo. The rest seems to work

16th January 2009

• extracted the pixel shaders patch from Radek Dulik/ Thorsten Behrens go-oo patches, will apply them to the cws
• extracted the fixes for the slides Radek Dulik/ Thorsten Behrens go-oo patches, will apply them to the cws

26th September

One issue verified on 42' screen : during OpenGL transitions, the view does not use the fullscreen area, but the Windowed view area (needs to check the exact area) -> work in progress, + some limitations (unimplemented features), explained below.

7th September

Excepted the flicker (caused be the slideshow itself) the transitions work. We have two working solutions, and a choice for the implementation will probably be done soon ( waiting from ssa, who will decide what is the best )

Remaining tasks:

• build issue in officecfg: the .xcs and .xcu files have to be modified when ENABLE_OPENGL is true
• check for memory leaks
• check for stability

31st August

FIXED: Fixed the colorspace issue: was the pDetectedFormat

TODO:

• Cleanup in void OGLTransitionerImpl::GLInitSlides()
• Continue to search what happens with the frame (why this sort of 'refresh ?' )
• Work in progress: started learning the slideshow

30th August

The issue with flicker seems to be caused by the slideshow itself. I'll add symbols in libsd, and I'll try to see what happens.

concerned code is in: sd/source/ui/slideshow

The color issue seems to be caused by some color/alpha channel ( RGBA .. RGAB ) or something like that issue.

Shane M. Mathews (I'm in contact with him) suggested several possibilites. I'll give them a try.

Issue 0 was not an issue. OpenGL version detected is at least 1.3, but can be more.

TODO: test on Leopard, just in case the issue is Tiger only (that would be a bad news)

Re-reading OpenGL Programming Guide. Tested a lot of possibilities with NSOpenGLContext, unsuccessfully.

Radek Dulik adviced me to check whether the context is really Double buffered (was an issue on Linux). Maybe a missing makeCurrentcontext somewhere (where ? )

Analyzed the known issues:

0) solved: OpenGL 1.2 or 1.3 detected (2.0 should work imho)

1) bad colors (bad OpenGL initialization?)Looks like the complementary color appears, of red effect added. Needs more work

2) offset in window mode, caused by scrollbar not included in the slide position computation(the frame dimensions are different)

3) flicker

the problem is (using ssa words):

• the slideshow displays the slide first
• then an opengl view is painted on top of it and plays the slide transition
• once it is removed the old background appears again still containing the first frame of the animation
• and after a very short time the slideshow engine draws the final frame,
• which is visible as a flicker

4) optimization / compatibility?

Works (experimental and hacked builds are available at Laurent Buisson site).

There are currently no crash, but it needs improvement:

• bad colors
• flickering at the end (will need precise and non trivial work)
• no optimization

other tests in progress: replace the NSOpenGLView, with a customized NSView ( sublassed as NSOpenGLView, with more possibilities)

cws state changed for new

added tasks and modules to the cws. First commits to come soon.

=> Important: don't forget to run autoconf in config_office, to regenerate configure (configure.in has been modified)

cws ogltrans4mac has been created (planned)

Stephan Schaefer helped me ( he made the NSOpenGLView work some weeks ago), and including all the changes, I was able to package a working version!

Created the patches concerning:

• scp2,
• config_office (René confirmed it is ok to bypass OpenGL / gl.h, glut.h headers and GLUT tests, and declare ENABLE_OPENGL=TRUE as default on Mac OS X),
• officecfg,
• sd,
• slideshow

Waiting for more information, about how proceed in vcl (I now know it works, but a big issue remains to be fixed :-) ).

Found why the libOGLTrans was not loaded: the registration as UNO_COMPONENT was not done.

Other issues : the new transitions effects are not listed, because not in the .xcu nor any .xml

I finally found where: in sd/xml! -> transitions-ogl (who is a plain .xml file) has to be

• renammed into transition-ogl.xml
• copied into the solver (accordingly to th esd/prj/d.lst file)

Consequence : some changes are needed in officecfg too:

Existing transitions are put in officecfg/registry/data/org/openoffice/Office/UI/Effects.xcu

-> new entries, matching with transitions-ogl.xml have to be entered (probably around line 1910, after 'Random Transition' effect)

FIXME : localisation of new transitions names?

Reading documentation (vcl code, mostly about outdev and co)

Defined the implementation plan (working with DEV300_m29)

Did some tests, using the first aquaOpenGLView I created. Lot of crashes.

Added other ideas

Started the wiki page and the implementation in parallel

PLEASE DO NOT REMOVE THE CREATION DATE

Page created Ericb 11:55, 22 August 2008 (CEST)

Concerned domains

• conditional activation of ENABLE_OPENGL in configure FIXME : OpenGL default or not on Mac OS X ?
• addition of NSOpenGLView class in vcl
• conditional build of libOGLTrans.dylib in slideshow
• conditional packaging of ligOGLTrans.dylib in scp2
• conditional addition of new transitions in the officecfg schema/UI files
• conditional registration of libOGLTrans.dylib at packaging time

• NSOpenGLView implementation in vcl
• OpenGL initialization and context creation in the slideshow
• load the libOGLTrans.dylib

• add the list of the new transitions in the list
• use them

Concerned modules

• configure.in (root of the sources): make OpenGL default on Mac OS X Aqua => ENABLE_OPENGL=TRUE
• slideshow: where the lib is built. This lib is linked with libvcl (vcl must be built before slideshow)
• scp2: to add the new lib in the package
• sd : rename the transitions-ogl in transitions-ogl.xml and deliver it
• officecfg : add the new transitions names in the list, to make them appear in the UI + add the transitions-ogl.xml file name in the matching Effects.xcs schema

Examples

Feedback

Opengl For Mac Os 10.13

The page below, is the place for user experience comments, suggestions and feddback.

Modifications

Existing (historical implementation)

Common:

vcl/source/opengl.cxx, implements:

• functions pointers (most important gl functions typedef'ed)
• + corresponding macro for functions initialization
• + impl functions getters
• Ctor: parameter pOutDev is a pointer on a OutputDevice*, using mpOutDev
• Dtor: deletes mpOGL
• usual methods ... and so on

vcl/source/salogl.cxx:

• Static members: oslModule (himpOGLLib libgl.dylib), NSOpenGLContext* .. (bool) state
• Macros
• Callbacks for CreateContext, DeleteContext, MakeCurrent, GetCurrentContext
• OpenGLWndProc (what's that ?)

vcl/source/gdi/outdev.cxx->there is a very interesting OpenGL* OutputDevice::GetOpenGL()

FIXME: To be continued

Concerned files / ideas

Ideas

27th August

Created the patches concerning:

• scp2,
• configure.in (René confirmed it is ok to bypass OpenGL / gl.h, glut.h headers and GLUT tests, and declare ENABLE_OPENGL=TRUE as default on Mac OS X),
• officecfg,
• sd,
• slideshow

Should be the only concerned modules. I used the OpenGL transitions listed in sd/xml/transitions-ogl.xml, but there are obvisouly more in slideshow/source/engine/transitions.

Waiting for more information, about how proceed in vcl (I now know it works, but a big issue remains to be fixed :-) ).

26th August:

I finally found why the libOGLTrans was not loaded: the registration as UNO_COMPONENT was not done.

Other issues : the new transitions effects are not listed, because not in the .xcu nor any .xml

I finally found where: in sd/xml! -> transitions-ogl (who is a plain .xml file) has to be

• renammed into transition-ogl.xml
• copied into the solver (accordingly to th esd/prj/d.lst file)

Consequence: some changes are needed in officecfg too:

Existing transitions are put in officecfg/registry/data/org/openoffice/Office/UI/Effects.xcu

-> new entries, matching with transitions-ogl.xml have to be entered (probably around line 1910, after 'Random Transition' effect)

FIXME : localisation of new transitions names?

25th august:

After reading a lot of code (mostly vcl), it appears this is not possible (excepted doing hacks), to use OpenGL without use outdev thing (got systematic crashes using NSOpenGLView directly, and outdev complains about lost events and pending pointers)

The consequence is, the slideshow calls must be abstraction of CreateContext, MakeCurrentContext, ReleaseContext ..etc.

And the real implementation must go in vcl/aqua/source/gdi/salogl.cxx, respecting vcl/source/gdi/opengl.cxx virtual classes.

The plan (to be confirmed seems to be):

• design the abstraction we'll use, and prepare the OGLTrans_TransitionerImpl.cxx like it is for Linux, but adapted to Mac OS X
• implement NSOpenGLView* pOpenGLView in vcl, guessing it will be sufficient (else, we'll have to implement a new class, but things will become complicated)
• define the NSView containing the scene, instantiate an OpenGLNSView using the same frame, and use addSubview. Current choosen Place to do that: OGLTrans_TransitionerImpl.cxx
• implement (using existing Windows and Linux implementation) the same classes / macros ( :-/ ) methods in salogl.cxx
• add the mac osx cases in outdev and anywhere else it is needed

Retry with the coming DEV300_m30

Possibilities:

Everything is based on implement an OpenGLView adding a new NSOpenGLView* pOpenGLView object in sysdata.hxx, or an NSView drawn as a subview of the (NSView * type) pView.

TODO: investigate about ImplOutdev and co

Try 1: either implement (NSView * type) pOpenGLView in vcl, more precisely, modify:

vcl/inc/vcl/sysdata.hxx

vcl/aqua/inc/salframe.h

vcl/aqua/inc/salframeview.h,

vcl/aqua/source/window/salframe.cxx

vcl/aqua/source/window/salobj.cxx

+ the makefile

and in slideshow:

slideshow/source/engine/OGLTrans/OGLTrans_TransitionImpl.hxx

slideshow/source/engine/OGLTrans/OGLTrans_TransitionImpl.cxx

slideshow/source/engine/OGLTrans/OGLTrans_TransitionerImpl.cxx

Issue is at buildtime:

Pb: visibility of the vcl/aqua/inc headers from slideshow at buildtime

Update: predeclaration in vcl/inc/vcl/sysdata.hxx will help a lot.

Main issue is, how to explain the compiler NSView* pOpenGLView has new methods (OpenGL specific), the NSView* pView has not ?

More precisely, there are warnings because the pOpenGLView is supposed receive no answer from the OpenGL specific methods used in OGLTrans_TransitionerImpl.cxx. In theory, it should work out of the box, but the code aims to be warning free; so this solution is not acceptable.

Workaround could be implement the new methods directly in the NSView, or delegate. Just wild guess [FIXME]

Try 2 or

(maybe completely wrong, but worth a try)

Implement the OpenGL methods directly in the SalframeView. just two methods have the same names/parameters numbers, so just rename they properly to avoid clash. Important: initWithFrame for OpenGL has two parameters, while initWithFrame for normal NSView has only one.

Try 3 or

Add an NSOpenGLView * pOpenGLView in the sysdata.hxx, and modify everything in vcl accordingly.

Thus, in OGLTrans_TransitionerImpl.cxx instanciate

an NSView who is a pointer on the normal NSView, and an NSOpenGLView, who is a pointer

or

create the AquaOpenGLView object directly in slideshow, modify the other slideshow files mentioned above (changes are similar)

Result

Using the second solution, the subview seems to -somewhat- show something.

Test: a right click in the transition demo, using the presentation wizard, give the same contextual menu we have in fullscreen (yes, this is weird, but this is encouraging for the future).

Known issue: there is no communication between the subView and the NSApplication, events are lost, timeout and chaos in event queue

-> deadlock and crash.

TODO: Second test will consist in delegate the notifications send for the refresh, to the NSApp.

It is expected, once this NSOpenGL view will work, this should be no problem to use it from the slideshow.

Communication between slideshow object and the NSApplication (customized NSView, itself inheriting of NSWindow) will use the notification center as proxy (what is extremely fast in theory).

Tasks and concerned files

configure.in + run autoconf Add the info in the cws comments for the RE !

Result: ENABLE_OPENGL=TRUE on Mac OS X Aqua // OK

slideshow/source/engine/OGLTrans/makefile.mk // OK

add the case Aqua, modify CFLAGSCXX + add fremaworks OpenGL, GLUT and Cocoa for linking

slideshow/prj/d.lst // OK

deliver the new lib on Aqua (libOGLTrans.dylib)

Other modified files in slideshow:

slideshow/source/engine/OGLTrans/OglTrans_TransitionImpl.cxx // OK

slideshow/source/engine/OGLTrans/OglTrans_TransitionImpl.hxx // OK

slideshow/source/engine/OGLTrans/OglTrans_TransitionerImpl.cxx // OK

Install Opengl On Mac

Must be done only if ENABLE_OPENGL is TRUE, and this environment variable must be turned in preprocessor macro:

scp2/source/impress/makefile.mk // OK

Package and registration of the lib :

scp2/source/ooo/file_library_ooo.scp // OK

scp2/source/ooo/makefile.mk // OK

Package and registration of the new file transitions-ogl.xml

scp2/source/impress/file_impress.scp // OK

Opengl Mac Os X Download

sd/prj/build.lst // OK

sd/prj/d.lst // OK

sd/xml/makefile.mk // OK ## New file to be created

sd/xml/transitions-ogl // OK to be renamed in transitions-ogl.xml and delivered in the solver, in solver/300/$build_type/xml

officecfg/registry/data/org/openoffice/Office/UI/Effects.xcu // OK

officecfg/registry/schema/org/openoffice/Office/Impress.xcs // OK

( the final file containing the new transitions will be OOO_BASE_DIR/share/config/soffice.cfg/simpress/transitions-ogl.xml )

Better solution : reuse the fix I provided in macmenusquit ( at packaging time, modify the .xml on the fly, using xsltproc)

New files who could contain the customized NSView if ever the NSOpenGLView does not work well (to be confirmed, not sure at all):

slideshow/source/engine/OGLTrans/aquaOpenGLView.h

slideshow/source/engine/OGLTrans/aquaOpenGLView.m

Issues attached to the task

TODO (draft)

Opengl For Mac Os X

• [DONE] build the OpenGL trans lib, warning free, on Mac OS X
  • [DONE] fix warnings and breakages, with empty implementation
  • [DONE] fix linking
  • [Done but needs work] create customized NSView (skeleton, and pre-implementation)
• [DONE] add the lib to the package
• [DONE] register the lib
• [DONE] rename the transitions-ogl in transitions-ogl.xml in sd and deliver it properly in the solver
• in officecfg, add the new transitions names in the list, to make them appear in the UI
• [DONE] in officecfg, add the transitions-ogl.xml file name in the matching Effects.xcs schema
• [DONE] Design the first implementation
  • design the abstraction used in slideshow
• [DONE] implement NSOpenGLView or customize an NSView [Current plan: try using NSOpenGLView first]
  • manage OpenGL context
  • manage OpenGL pixels mapping
  • manage colors
  • manage events and notifications critical
  • initialize the view properly in splitted view
  • manage geometry
  • [WORKS] implement the fullscreen mode
• finalize the transitions integration in Aqua bundle
• [DONE] make transitions work
• work on the flickering issue with last image
• test
• integrate

LINKS

Below a now exhaustive list of links. Feel free to add interesting links.

COMPLETE ME

Opengl Osx