Hacker News Reader

Comment by purpleflame1257 | Hacker News Reader

That Photoshop was probably CS2 IIRC. I'm fairly sure that software bloat has eaten all the speed gains from faster processors. I have an old 1.33 GHz Powerbook which runs 2004 Word as fast as my M1 macbook runs Office today. If I put in an SSD it might even be faster.

View on HN

In 2001 I was using a G4 with Mac OS 9.2 for Photoshop while working at a studio; that was Photoshop version 7, which is pre-CS (which started with 8.0). My memory of the workflow at that time was that most system operations were snappy as hell. Sure, there was a bit of load time for very large files and some of the operations had a bit of lag but there really became a point around that time that the speed of work that you could do for most operations essentially matched the speed of the machine. Before that era, I remember going to use the cloning tool on a large, high-DPI image and getting a lag as you dragged the brush over a spot... waiting for it to catch up. The G4, especially when we upgraded one with more ram and OSX (which also was a huge change that happened to coincide with the G4) is when I remember machines getting to the point where I wasn't waiting on lag all the time when working.

I used both a 1Ghz iMac G4 and 2Ghz iMac G5 (ALS model) in the 2000s for a lot of Photoshop work and remember them performing similarly. Both were excellent machines for that particular use case and zipped through anything I threw at them in PS, especially the G5 which I put 2GB of RAM in.

The PS versions I used were chiefly 7.0 and CS1, with some CS2 mixed in towards the end of the G5’s lifespan. I miss those versions so much because they sat at nearly a perfect nexus of features, responsiveness, and resource consumption. Such a stark contrast to PS CC.

> If I put in an SSD it might even be faster.

I think most of the retro youtubers I've seen have done this mod along with PRam battery replacements that don't leak. They seem to use the m.2 SATA mode drives to 44pin like thus (not recommending, just showing an example) https://www.amazon.com/44pin-Converter-Adapter-Computer-Acce...

OpenBSD for macppc would run perfectly fine and fast enough on that.

Not for JS heavy sites, but Seamonkey with UBlock Origin Legacy would do a great job.

For youtube, Mplayer and yt-dlp would do the job. SMPlayer + "open url" dialog for graphical folks.

Do you think the g4 would have enough juice to do software decoding of h264 in real time? (slash is ffmpeg optimized enough for a relatively obscure platform like macppc? e.g. does it actually use altivec?)

IDK on FFMPEG, but for sure MPlayer had altivec support from the G4 days.

Also, pair a good video card with XV/XVMC support.

Also, for last drip of perfomance:

   mplayer -lavdopts skiploopfilter=all file.mkv

    mplayer -lavdopts skiploopfilter=nonrefs file.mkv

mplayer uses ffmpeg to decode h264.

MPlayer primarily uses libavcodec (the -lavd in your command line refers to it) for decoding, which is part of ffmpeg: https://ffmpeg.org/libavcodec.html

There was a lot of overlap in MPlayer and ffmpeg in the early days. Things like both projects sharing the same infrastructure, MPlayer developers automatically getting commit access to ffmpeg, ffmpeg sources having references to MPlayer, several top developers active in both, etc.

It's to the point that I think of ffmpeg as a spin-off of MPlayer, but perhaps that's not fair. Maybe it's more accurate to say that several prominent MPlayer developers (and infrastructure folks) did double-duty for years, then many drifted over to working on ffmpeg exclusively. I know that's true for several lead folks. I'd have to go through the ancient mailing list archives to sharpen my recollection of events. Perhaps somebody else who was also around at the time recalls a clearer perspective.

IDK but before the ffmpeg(1) tool everyone used mencoder (and transcode(1) ) to transcode media.

DVD ripping used transcode and/or mencoder.

ffmpeg has dedicated code for decoding h264 on ppc, as well as all the support code for rescaling and yuv->rgb conversion etc. It's probably not going to be able to decode super ultra duper high bitrate h264, but I would expect it to be able to decode 24fps 720p at standard bitrates without breaking a sweat, and it probably ought to be able to handle 30fps 1080p.

https://github.com/FFmpeg/FFmpeg/tree/master/libavcodec/ppc https://github.com/FFmpeg/FFmpeg/tree/master/libswscale/ppc

Reply on news.ycombinator.com