Adobe brengt releaseversie van Photoshop uit voor Macs met Apple M1-soc

Adobe heeft de Arm-versie van Photoshop voor Mac-computers met Apple M1-soc's uitgebracht. De software was sinds vorig jaar al beschikbaar als bètaversie, maar wordt nu uitgerold naar alle Adobe CC-gebruikers met een Apple M1-apparaat.

De native Apple M1-versie van Photoshop komt per direct beschikbaar. Adobe claimt dat 'verschillende functies' binnen de nieuwe M1-softwareversie tot gemiddeld anderhalf keer beter presteert dan x86-Photoshop op 'soortgelijk uitgeruste' systemen van de vorige generatie. Adobe stelt verder dat de prestaties in de toekomst verder geoptimaliseerd zullen worden.

Het bedrijf laat weten dat enkele functies uit de x86-build van Photoshop nog niet beschikbaar zijn in de Apple M1-versie. Het gaat volgens Adobe voornamelijk om functies die recent zijn toegevoegd aan de fotobewerkingssoftware. Het bedrijf noemt de 'Invite to Edit'-functie voor clouddocumenten en het synchroniseren van presets als voorbeelden voor ontbrekende functies. Gebruikers met een Apple M1-systeem die deze functies nodig hebben, kunnen de x86-build nog steeds gebruiken via Rosetta 2-emulatie.

Adobe brengt ook twee nieuwe functies voor de iPad-versie van Photoshop uit. Gebruikers kunnen nu de versiegeschiedenis van clouddocumenten bekijken. "Omdat clouddocumenten automatisch worden opgeslagen, heeft elk document ook een versiegeschiedenis. Gebruikers kunnen tot zestig dagen van deze versiegeschiedenis bekijken en oude versie herstellen." Oude versies van documenten kunnen daarnaast gebookmarkt worden, zodat deze permanent beschikbaar blijven. Photoshop for iPad-gebruikers kunnen met de nieuwste versie ook offline toegang krijgen tot clouddocumenten.

Afbeelding via Adobe

Reacties (57)

[mocean]

Waarom is er geen compiler mogelijk die met 1 broncode meerdere architecturen aankan? Of is dat wel mogelijk maar niet efficient...

[johnkeates]

Die zijn er, dat zijn namelijk zo'n beetje alle compilers.
Check https://en.wikipedia.org/wiki/List_of_compilers bijvoorbeeld: ALGOL 68, die heeft targets voor verschillende ICL architecturen, System/370, Sun-3, SPARC, Odra, PDP-10 om maar wat te noemen.

Als je bijv. specifiek naar GCC kijkt: https://gcc.gnu.org/backends.html dan heb je toch best een bak aan architecturen die je vanaf 1 broncode kan gebruiken als doel om voor te compileren: arch64, alpha, arc, arm, avr, bfin, c6x, cr16, cris, csky, epiphany, fr30, frv, gcn, h8300, i386, ia64, iq2000, lm32, m32c, m32r, m68k, mcore, mep, microblaze, mips, mmix, mn10300, moxie, msp430, nds32, nios2, nvptx, pa, pdp11, powerpcspe, pru, riscv, rl78, rs6000, rx, s390, sh, sparc, stormy16, tilegx, tilepro, v850, vax, visium, xtensa.

Uiteraard is een architectuur als compileer-doel kunnen gebruiken niet het enige wat relevant is, zo kan het zijn dat je een bepaald OS wil inzetten en daar faciliteiten van wil benutten, en die zijn niet universeel beschikbaar. Zo heeft XNU op macOS Mach Ports en Windows niet. En Windows heeft dan weer Named Pipes maar macOS heeft dat niet. Dus als je een stukje code hebt dan een van de twee specifiek aanspreekt dan kan je het wel voor meerdere architecturen compileren, maar dan werkt het nog steeds niet.

Behalve het compileren van de broncode moet je ook een executable maken als je een programma wil hebben dat op zichzelf kan draaien. Dan moet je dus niet alleen wat broncode omzetten naar machinecode, maar ook verpakken en extra data bijvoegen. Dan krijg je voor Linux een ELF binary, en voor Windows een PE binary en voor macOS een Mach-O binary. Dat is niet architectuur-specifiek, maar OS-specifiek.

Dan heb je nog de eerder genoemde CPU-specifieke functies, ARM heeft NEON, Intel heeft AVX, en als je een van die twee specifiek inzet kan je code dus niet op de CPU van de ander draaien. En je hebt uiteraard ook beperkingen zoals frameworks of code van derden die je gebruikt die misschien niet overal op kan functioneren. Je kan dan kiezen dat zelf dan te herbouwen zodat het wel kan, maar op dat punt ben je een geheel nieuw OS aan het maken...

[Reactie gewijzigd door johnkeates op 30 juli 2024 16:41]

[- peter -]

Grotendeels zal de C++ codebase gewoon gecompiled kunnen worden naar x86 en ARM. Wat mist dan zijn de optimalisaties en dergelijke die in CPU specifieke code geschreven zijn. Bijv SSE of AVX code. Dat moet herschreven worden naar ARM NEON.

[Wulfklaue]

Die zijn er ... GoLang, Rust, ... Kunnen allemaal X86, X86-64, ARM, ... aan en cross compilen op dezelfde source.

Het ding voor Adobe is dat men specifieke hardware acceleratie aanspreekt dat in aanwezig in de M1 chip. Dit om bijvoorbeeld filters enz sneller te maken. En die dingen moet je custom programmeren specifiek voor de M1. Je kan dat zonder de hardware acceleratie doen en puur op de CPU, maar dan is je resultaat (vaak een pak) minder snel.

[mjz2cool]

Het probleem is meer de OS specifieke dingen en de executables die je voor verschillende OS-en moet maken.

[Emiel L]

In dit geval niet, want ze hebben al een cross platform codebase. Photoshop is immers beschikbaar voor Windows en voor de Mac. De compiler van Apple ondersteunt compileren voor zowel X86 als Arm64, maar zaken als SSE en AVX, moet Neon worden. Er zit wat werk in om zulke code om te schrijven.

Wat me verbaast is dat een functie als 'invite to edit' dan weer niet een kwestie van even opnieuw compileren is; wat kan daar nou voor platform specifiek spul in zitten?

[Joolee]

Ik vermoed dat dat vooral komt omdat "Het M1 team" aan het werk is gegaan met een codebase die enige tijd geleden is vastgezet op een specifieke versie. Die zullen ze nu vast hard aan het mergen zijn naar de algemene master repo. Adobe geeft zelf ook aan dat het vooral nieuwe/recent toegevoegde functies zijn die nog niet werken.

[Wolfos]

Het probleem zit 'm meer in de rest van het buildproces. Er moeten automatische builds geproduceert worden met ARM64, en er moeten ARM64 machines komen om deze builds te testen.

Verder is het mogelijk dat Photoshop wat inline assembly gebruikt, aangezien ze redelijk wat performance-intensieve dingen doen. Die code is in z'n geheel afhankelijk van de processor waar het op draait.

[Reactie gewijzigd door Wolfos op 30 juli 2024 16:41]

[Knijpoog]

Ik was vrij sceptisch over de eerst ARM chip voor Mac van Apple maar dit gaat echt hard zo. Een goede opvolger kan al echt gamechanger gaan zijn.

[MenN]

Inderdaad, en vooral als je dit bijv afzet tegen alle pogingen die Microsoft heeft gedaan in de afgelopen jaren met nieuwe windows varianten, of de ARM versie van windows 10. De adoptie daar is schrikbarend laag, daar draait alles om hoe goed het win32 applicaties kan supporten.

Je kan van alles zeggen over Apple, maar deze ARM transitie zit vanaf het begin gewoon top in elkaar. Rete snelle support met Rosetta en een ongelofelijk tempo in applicaties die al native ARM versies uitbrengen.

[PvdVen777]

Ik ben allerminst een Apple fan maar als buitenstaander ervaar ik het toch als dat Apple bij dit soort transities de targets heel duidelijk en de regie strak in handen heeft.

[Isarna]

Dat is ook een stuk makkelijker als je zowel de hardware als de software ontwerpt

[ronaldmathies]

Microsoft Surface apparaten zijn toch ook door Microsoft ontworpen? De silicon misschien niet maar dat zou weinig uit moeten maken. De strategie is gewoon anders. De support vanuit Apple is naar mijn idee bij dit soort situaties altijd heel sterk.

[BugBoy]

De Apple ARM architectuur bevat een speciaal onderdeel om de Intel-code met fatsoenlijke snelheid te kunnen draaien. Dat is één van de redenen waarom die Intel-emulatie zo ontzettend goed is. Een ander verschil is dat het duidelijk is dat Intel bij Apple gewoon klaar is over een paar jaar. Bij Microsoft is het hele ARM-verhaal nogal halfbakken en zal Intel de komende jaren gewoon dominant blijven op het platform. Daardoor zijn softwaremakers ook veel minder genegen om hier werk in te steken. Het zou ook niet de eerste keer zijn dat MS de stekker eruit trekt en dan is je investering weg. Ik noem een Windows RT, Windows Phone, ...

Maar ook het hele cross-platform (UWP) verhaal is een drama. Allemaal halfbakken producten en MS weet zelf niet wat te gebruiken. Gebruik je C++ of toch maar .NET en kies je dan Xamarin, Blazor of MAUI? Die laatste drie zijn echt alle drie halfbakken producten die stijf staan van de bugs. Bij elke update is niet de vraag of er wat omvalt, maar meer wat en hoeveel er omvalt. Microsoft heeft ook AppCenter en daarmee kan je iOS, Android en UWP apps bouwen. Publishen naar de AppStore (iOS) en Google Play Store (Android) wordt prima ondersteund, maar Windows app kan je niet automatisch pushen naar de eigen Windows Store (ook alweer zo'n halfbakken product).

Overigens zie je dat sommige grote fabrikanten (bijv. Logitech) ook Apple silicon links laten liggen. Erg jammer, want ondanks dat ik de M1 erg goed vind, zitten er toch ook nog steeds wel flink wat nadelen aan vanwege software die niet native beschikbaar is. Voor de doorsnee consument is het prima, maar een die-hard programmeur mist nog wel het e.e.a. Het gaat gelukkig wel snel de goede kant op.

[RockmanX]

"De Apple ARM architectuur bevat een speciaal onderdeel om de Intel-code met fatsoenlijke snelheid te kunnen draaien." Dit is feitelijk onjuist. Wat apple heeft is Rosetta 2. Software die er voor zorgt dat x86 code op de ARM chip kan draaien. De Arm chip is zoveel sneller dan de intel chips dat de 30% verlies die ze maken bij de conversie prima opgevangen kan worden. Lees hier meer over op: https://developer.apple.c...a-translation-environment

[BugBoy]

Microsoft gebruikt daadwerkelijke emulatie, waarbij Rosetta 2 gebruik maakt van AOT. Daarbij wordt de Intel-code omgezet naar ARM-code en daarbij kan je de nodige optimalisaties uitvoeren en na conversie draai je "native" ARM-code. Dat maakt Rosetta 2 zoveel sneller dan de Intel-emulatie die MS doet, waarbij elke Intel instructie elke keer weer geëmuleerd wordt.

Linus heeft er een goede video over hoe dramatisch Microsoft het heeft aangepakt: https://www.youtube.com/w...&ab_channel=LinusTechTips. Ik dacht daarin ook gehoord te hebben dat er speciale optimalisaties in de chip zaten om sneller Intel-code te kunnen draaien. Maar ik kan daar inderdaad verder niets over vinden, dus wellicht dat het niet klopt.

[Grauw]

Weet je dat zeker, dat Apple niet extra instructies of registers of andere extensies heeft toegevoegd aan hun ARM implementatie zodat Rosetta 2 sneller kan werken? Daar heb ik namelijk (op Youtube) wat over gehoord, ik heb er verder geen details over gelezen dus ik weet niet of het klopt, maar ik kan het me wel goed voorstellen.

[Reactie gewijzigd door Grauw op 30 juli 2024 16:41]

[hiostu]

Microsoft ecosysteem is veel meer dan alleen Surface. Appel zegt gewoon: alles is vanaf nu ARM. Dus software ontwikkelaars moeten wel. Bij Microsoft zou het zijn: Surface is ARM, oh en Dell, zelfbouw, HP, Lenovo, servers, etc etc blijft nog gewoon x64.

Dus die situatie is niet te vergelijken.

[mjz2cool]

Dat klopt, maar ontwikkelaars zijn bij Windows niet afhankelijk van Microsoft. Als je ARM dan niet ondersteund merk je daar niks van als ontwikkelaar. Als je Apple wilt ondersteunen moet je wel naar ARM, want er is straks gewoon geen x86 meer bij Apple, althans, geen nieuwe hardware meer wanneer ze helemaal over zijn.

[The Zep Man]

Inderdaad, en vooral als je dit bijv afzet tegen alle pogingen die Microsoft heeft gedaan in de afgelopen jaren met nieuwe windows varianten, of de ARM versie van windows 10. De adoptie daar is schrikbarend laag, daar draait alles om hoe goed het win32 applicaties kan supporten.

Backwards compatibility is bij Windows een zwaarder wegend onderdeel dan bij macOS. Een stuk software van 25 jaar oud? Zolang het 32 bit gecompileerd is en geen gekke dingen doet met iets als drivers, werkt het gewoon.

Bij macOS is deze periode een stuk korter.

[Maurits van Baerle]

Ja, Microsoft hangt erg aan backwards compatibility, Apple erg aan vooruitgang. Er valt voor allebei de strategieën wat te zeggen.

Een vergelijkbaar voorbeeld is de overstap van 32 bits naar 64 bits. Microsoft begon daar jaren eerder aan dan Apple maar Apple was er jaren eerder mee klaar. Die ondersteunen nu al een tijd geen 32 bit hardware of software. Je moet maar bijblijven.

[RebelwaClue]

Microsoft heeft natuurlijk als groot nadeel dat het enorm vertegenwoordigd is in de zakelijke wereld, zowel op kantoor als in het productieproces. En daar zijn nu eenmaal een shitload aan programma's die moeten blijven werken. Dat merk ik wel hoe veel grote bedrijven tegenover Windows updates staan, huiverig om de laatste versie te installeren want stel je voor dat pakket X niet meer werkt of pakket Y rare kuren vertoond.

Dit heb je in mindere mate bij de Mac om dat de meesten hem gebruiken voor meer doorsnee applicaties.

[Banix]

Pakket x en pakket y zijn dan vaak ook al 20 jaar oud en het bedrijf heeft geen behoefte gehad die stukken software te updaten naar een nieuwere versie omdat dat geld kost. Althans dat is mijn ervaring.

[Aeternum]

Vanuit ecologisch standpunt is er wel wat te zeggen voor de microsoft manier.

[bzzzt]

Die ARM cpu's zijn anders een stuk energiezuiniger

[mjz2cool]

Dat komt denk ik ook meer omdat als je Apple wilt ondersteunen, dat je dan wel moet overgaan naar ARM. Bij Windows ondersteun je dan gewoon ARM niet, dan blijven er nog zat x86 systemen over.

[badflower]

De M1 gaat inderdaad hard, en dan heb ik het over de Rosette Intel emulatie. Die blaast mijn 2 jaar oude macbook al weg (i9) met development. Build times, testen, alles gaat significant (als in seconden) sneller. Qua beeldbewerking is er trouwens al tijdje Affinity native voor M1.

[Aeternum]

Werd die intel niet heel hard geknepen door warmte problematiek? Dat levert wel een redelijk onevenwichtig beeld op.(eindresultaat is natuurlijk wel hetzelfde)

[bzzzt]

Valt wel mee, door iets te agressief energiebeheer was de i9 toen die uit kwam niet veel sneller dan een i7. Dit is toen gefixed, maar i9 blijft hoe dan ook een warmtekanon - en dat is niet specifiek voor Apple.

[BikkelZ]

Het bedrijf laat weten dat enkele functies uit de x86-build van Photoshop nog niet beschikbaar zijn in de Apple M1-versie. Het gaat volgens Adobe voornamelijk om functies die recent zijn toegevoegd aan de fotobewerkingssoftware. Het bedrijf noemt de 'Invite to Edit'-functie voor clouddocumenten en het synchroniseren van presets als voorbeelden voor ontbrekende functies.

Raar. Je zou verwachten dat er x86-specifieke machine code instructies in super geoptimaliseerde loops zoals filters zou zitten maar dit is allemaal fluffy cloud stuff wat net zo goed in Python geschreven zou kunnen zijn.

[Aaargh!]

Raar. Je zou verwachten dat er x86-specifieke machine code instructies in super geoptimaliseerde loops zoals filters zou zitten

Het zijn recent toegevoegde functies. Dat doet vermoeden dat ze een tijdje terug hun source repo gebranched hebben en die branch hebben geport naar ARM. Een port maken van een steeds veranderende codebase is niet handig, dus je doet dat met een stabiele versie.

[BikkelZ]

Oh het is echt een feature die een maand geleden gelanceerd is, ik kan me daar nog wel iets bij voorstellen. Maar dan zou het vanaf nu niet veel moeilijker moeten zijn om builds gelijktijdig uit te brengen, tenslotte zit er CPU-technisch niks spannends in "Invite to edit".

[Verwijderd]

Als het allemaal zó makkelijk zou zijn... Stuur Adobe een mailtje met je suggestie.

[BikkelZ]

Netwerk code en business logica is gewoon prima cross platform te compileren. Zijn zelden de hot paths binnen je applicatie.

[oef!]

Dikke kans dat ze originele, slechte code hebben moeten herschrijven omdat het gebruik maakte van instructies die niet aanwezig zijn in de M1.

[Grauw]

Vanwaar de kwalificatie “slechte code”? Als bepaalde stukken code (codecs, filters, e.d.) zwaar met assembly zijn geoptimaliseerd maakt dat de code niet goed of slecht. Het is echter niet portable, je moet dat herschrijven in ARM assembly, en dat kost tijd.

[Reactie gewijzigd door Grauw op 30 juli 2024 16:41]

[ikweethetbeter]

Raar. Je zou verwachten dat er x86-specifieke machine code instructies in super geoptimaliseerde loops zoals filters zou zitten maar dit is allemaal fluffy cloud stuff wat net zo goed in Python geschreven zou kunnen zijn.

Klopt. Mogelijk hebben ze dat deel niet zelf geschreven.

[ikweethetbeter]

Ik ben benieuwd waarom Adobe geen Universal Binary uit heeft gebracht...

[Blokker_1999]

Omdat die veel groter zal zijn. Photoshop is geen klein stukje software en het overgrote deel ervan is pure code en dus uniek voor elk platform waar het op draait. Met een universele binary is de kans dus groot dat je software bijna dubbel zo groot in omvang zal zijn, En dat zonder dat je ert eigenlijk een groot voordeel uit haalt.

[ikweethetbeter]

Omdat die veel groter zal zijn.

Groter: ja, zonder twijfel.
Veel groter: nee. Vensters, werkbalken, menu's, teksten, ..., die komen allemaal enkel voor. Alleen echte programmacode wordt verdubbeld.

Photoshop is geen klein stukje software en het overgrote deel ervan is pure code en dus uniek voor elk platform waar het op draait.

Veel code maakt gebruik van frameworks / bibliotheken. De meeste code is geen machinecode (x64 of ARM instructies), en hoeft daardoor niet dubbel te worden uitgevoerd.

Met een universele binary is de kans dus groot dat je software bijna dubbel zo groot in omvang zal zijn, En dat zonder dat je ert eigenlijk een groot voordeel uit haalt.

Het grootste voordeel is dat je maar één versie hoeft te onderhouden. En voor gebruikers met een oude en een nieuwe Mac is het ook handig.

[- peter -]

Alle code is machine code. Tenzij ze code op een Java VM of Python interpreter draaien. Maar Photoshop zal in C++ geschreven zijn en gecompiled naar native x86 of ARM. Oftewel, reken dus wel op een verdubbbeling, gezien er alleen wat icon assets zijn die ze kunnen delen.

[MiesvanderLippe]

Je doet je naam eer aan, maar je slaat de plank wel echt volledig mis...

[Kapotlood]

Had Adobe in de tijd van de overstap van PowerPC naar Intel niet ook een Universal Binary eigenlijk? Er staat me ergens iets van bij dat dat het geval was namelijk, en dat het wel groter was, maar geen dramatisch groot verschil?

[ikweethetbeter]

Precies dat.
Ik heb de vorige overgang ook meegemaakt, en de meeste programma's waren niet veel groter.

[vliegendehommel]

Zou het misschien komen omdat ze op deze manier gerichter kunnen optimaliseren?

[Groningerkoek]

UB is uiteindelijk weinig meer dan 2 compilaties in 1 pakket, dit was bij de overgang naar Intel als men Apple trademarks wilde voeren een eis van Apple om de overgang gemakkelijker te maken voor de gebruiker, maar nu is die eis er niet dus hoeft men niet iedereen een dubbel pakket te geven maar kan er maatwerk aan de klant gegeven worden. Het verschil in die eis wel of niet voeren zit hem denk ik in de introductie, de Silicon Apples zijn ruim van te voren aangekondigd en er was veel sneller veel software beschikbaar waarbij de overgang naar Intel velen werden verrast omdat de aankondiging van de nieuwe serie slechts enkele dagen was voordat deze in de verkoop kwam. (Zo had ik zelf ruim 2 week van te voren net 2 PowerPC iMacs gekocht en was zeer blij dat de UB eis er nog geruime tijd was.)

[JustVodka]

Ik kan Apple Silicon / M1 versie op dit moment helaas nog niet downloaden.

Ik hoop wel dat ie minder geheugen slurpt dan z'n M1 Lightroom CC broertje.
M1 versie Lightroom CC rond de 10GB ram. (niet met Intel getest) De Windows Intel versie 1,9GB met zelfde catalogus/sync.

Geheugen gebruik is vrijwel gelijk tussen Mac M1 en Mac Intel versie. Gebruikt iets minder geheugen dan de Windows versie.
En inderdaad, de M1 versie in aanmerkelijk sneller. Brushes soepeler, diverse filters sneller!

Fijn.

[Reactie gewijzigd door JustVodka op 30 juli 2024 16:41]

[ikweethetbeter]

De meeste software pakt het geheugen dat ze kunnen / mogen pakken. Het kan zijn dat de Mac meer vrij geheugen heeft, of dat de Windows versie meer aan het swappen is.

[JustVodka]

Nee, helaas hier dach ik ook al aan. Maar ook wanneer ik andere hongerige apps open pakt de m1 versie zo'n 10gb en moet er flink veel geswapped worden. Swappen moet ie ook gelijk al wanneer er geen andere apps open zijn.
En dat terwijl er bij Windows gewoon nog ram vrij is.

Of Adobe is erg slecht met memory management met de M1 Lightroom versie of er zit ergens nog een bug in.
Photoshop is in iedergeval netter met geheugen.

[mjz2cool]

Hoeveel ram heb je dan? Als die al swap aanspreekt zonder andere apps heb je te weinig ram, of de applicatie is erg slecht geoptimaliseerd. Het kan inderdaad wel zijn dat de applicatie meer ram toewijst omdat er meer vrij is en niet gereserveerd, maar dan zou die geen swap aan moeten spreken.

[JustVodka]

Ik heb even een test gedaan door oude intel versie te proberen op m'n Macbook Air m1 16gb.
Lightroom intel macos 2,3GB ram.
Lightroom apple silicon 10,7GB ram.
Lightroom windows intel 1,9GB ram.

Memory usage loopt ook niet noemenswaardig op, dus lijkt niet op memory leak oid.
Maar zo'n 5x meer ram lijkt me niet de bedoeling. Lijkt me voor lightroom ook niet zo zinvol. Catalogus is zo'n 500MB, het zou kunnen dat hij nu alle thumbnails en smart previews in ram wil houden. Mijn catalogus bestaat nu uit ongeveer 6000 45mpix en lagere foto's. Wanneer Lightroom dat zou doen wordt het leuk voor professionals met catalogus met tientallen tot honderdduizenden foto's.

[Reactie gewijzigd door JustVodka op 30 juli 2024 16:41]

[mjz2cool]

6000 45mp foto's, en dan maar 500MB? Ik zit met +-3500 foto's al op 15GB, maar dan zit daar wel raw tussen.
Maar je hebt wel een punt, die 10.7GB aan ram is wel een beetje veel, vooral als de Intel versie (in ieder geval op x86) maar +- 2GB "gebruikt". Misschien dat die juist wat meer geheugen gebruikt omdat het beschikbaar is, dat hij alvast een stukje geheugen reserveert.

[JustVodka]

Met catalog file bedoel ik eigenlijk in Lightroom Classic termen de database met changes/settings per foto incl alle idividuele brush strokes van selective edits etc worden daar in opgeslagen. Lichtroom CC cached die catalog/database ook lokaal op disk. En die is ongeveer 500MB bij mij.

Maar mijn foto collectie zelf is ongeveer 65GB.

[Aeternum]

De snellere m1 vat ik niet helemaal.... echt een goed vergelijk valt niet te maken "denk ik" omdat de m1 in de cpu zelf een grafische core heeft met alle zaken en de intel/amd afhankelijk is van de grafische kaart... Terwijl (als ik he goed zie) de m1 minder zou presteren "vermoed ik" bij het draaien van vmware door het ontbreken van native Virtualization. Iemand enig idee of dit uberhaupt goed testbaar is.

[R1ck3rd]

Nu nog een fix voor Adobe Acrobat Pro waar we tegenaan lopen op het werk .

[DePruus]

Raar dat de nieuwe functies niet werken, je zou verwachten dat uit die code al geoptimaliseerd is voor nieuwer systemen. Raar.