PyObjC がトンデモなく遅い

今日は久しぶりに PyObjC で小物を作ろうとした。
いやまあ macOS プログラミングは完全に放置気味でしたね。
ということでまずアップグレードを行なってと。

# pip Upgrade
pip3 install --upgrade pip

# PyObjC Install or Upgrade
pip3 install -U pyobjc

で本題、PyObjC コードの初期化がありえないほど遅い。
NSWindow を作ったら表示されるまで十秒くらい待たされる。
Python 標準モジュールのみのコードなら普通に一瞬だ。
しばらく色々試したらこういうことだった。

#!/usr/bin/env python3

'''
    app.old.py
'''

import time
start = time.time()

from AppKit import *
import objc

class AppMenu(NSMenu):
    def init(self):
        objc.super(AppMenu, self).init()
        item_app  = NSMenuItem.new()
        self.addItem_(item_app)
        menu_app = NSMenu.new()
        item_app.setSubmenu_(menu_app)
        # command+Q で閉じるメニュー
        item_quit = NSMenuItem.new()
        item_quit.initWithTitle_action_keyEquivalent_('Quit App', 'terminate:', 'q')
        menu_app.addItem_(item_quit)
        return self

# NSApp を作る
NSApplication.sharedApplication()
# command+Q で終了するメニューを入れる
NSApp.setMainMenu_(AppMenu.new())
# コレをしないと最前面に出てこない
NSApp.activateIgnoringOtherApps_(True)
# メインループを回さない
#NSApp.run()

# 経過時間 ms
print(f'{time.time() - start} ms')

from を使う今までやっていたコード。

#!/usr/bin/env python3

'''
    aoo.new.py
'''

import time
start = time.time()

import AppKit, objc

class AppMenu(AppKit.NSMenu):
    def init(self):
        objc.super(AppMenu, self).init()
        item_app  = AppKit.NSMenuItem.new()
        self.addItem_(item_app)
        menu_app = AppKit.NSMenu.new()
        item_app.setSubmenu_(menu_app)
        # command+Q で閉じるメニュー
        item_quit = AppKit.NSMenuItem.new()
        item_quit.initWithTitle_action_keyEquivalent_('Quit App', 'terminate:', 'q')
        menu_app.addItem_(item_quit)
        return self

# NSApp を作る
AppKit.NSApplication.sharedApplication()
# command+Q で終了するメニューを入れる
AppKit.NSApp.setMainMenu_(AppMenu.new())
# コレをしないと最前面に出てこない
AppKit.NSApp.activateIgnoringOtherApps_(True)
# メインループを回さないさない
#AppKit.NSApp.run()

# 経過時間 ms
print(f'{time.time() - start} ms')

都度プリフィクスを書く面倒くさいコード。

PyObjC

from で * を使うとトンデモネェ遅さになってしまった。
以前は from でも同じような速度で初期化されていたんですが。
NSApp だけでコレ、NSWindow まで作るとすげぇ悲惨。

Python 3.11 からの高速化の弊害なのかな。
from は全部辿ってキャッシュとかになっていたらまあこうなるよな。
いや PyObjC 側の不具合かもしれないけどプリフィクス化で解決するし。
Cocoa のメソッド名長いんだよな、GTK+ みたくできないのかと。
アスタリスクを使っている人は調べてみたほうがいいかも。

ついでに、objc は import しなくてもよかったのに必須になった。
activateIgnoringOtherApps が動作しない、何故?
ちょっと放置しすぎたな、もう少し調べよう。
秋の渡り鳥が来る前にやらないとまた放置しそうだし。

MPV AspectRate Change (2024)

いつのまにか MPV にてアスペクト比変更ができなくなっていた。
いや Shift+a での変更は可能、自作した拡張 Lua スクリプトが動かない。

How to add 21:9 Aspect ratio option in MPV Android? : r/mpv

色々探して上記を見つける。
video-aspect-override という property があるのね。

--mp.set_property('video-aspect', aspects[aspect_num])
mp.set_property('video-aspect-override', aspects[aspect_num])

これで動いた、思っていたより簡単でよかった。
Fedora の MPV は更新されていないし ffmpeg 側の仕様変更かな?
なので環境によって変わると思う、Fedora 40 な人は書き換え必須です。

せっかくなので Shift 追加で逆順変更機能も付けてみよう。

-- ~/.config/mpv/scripts/mpv_aspect_rate.lua

-- Shift+a でアスペクト比は変更できますけど
-- スマホの縦動画用が足りないので独自に作ってみました

local aspect_num = 0
local aspects = {'4:3', '16:9', '9:16', '3:4', '1:1', '3:2', '2:3'}

function on_change_aspectrate()
    aspect_num = aspect_num + 1
    if aspect_num > #aspects then
        aspect_num = 0
        --mp.set_property('video-aspect', '-1')
        mp.set_property('video-aspect-override', '-1')
        mp.osd_message('Aspect Rate @ Default')
    else
        --mp.set_property('video-aspect', aspects[aspect_num])
        mp.set_property('video-aspect-override', aspects[aspect_num])
        mp.osd_message('Aspect Rate @ '..aspects[aspect_num])
    end
end

function on_change_aspectrate_r()
    aspect_num = aspect_num - 1
    if aspect_num == -1 then
        aspect_num = #aspects
    end
    if aspect_num == 0 then
        mp.set_property('video-aspect-override', '-1')
        mp.osd_message('Aspect Rate @ Default')
    else
        mp.set_property('video-aspect-override', aspects[aspect_num])
        mp.osd_message('Aspect Rate @ '..aspects[aspect_num])
    end
end
mp.add_key_binding('Ctrl+t', 'aspectrate_func', on_change_aspectrate)
mp.add_key_binding('Ctrl+Shift+t', 'aspectrate_r_func', on_change_aspectrate_r)

こんな感じになった。

しかし Kate は今だに使い辛いなぁ。
コードやブログネタを書いて余計な補完機能を見つけて無効化するばかり。
macOS で Sublime Text は Gedit でやっていたことを再現できたんだけど。
Kate は無理っぽい、でも Gedit は死亡したも同然だし代わりも見つからない。

熱中症アラート

盆休みです、本日は名古屋で野暮用。
クソ暑いけれど午後から鶴舞公園に行ってみました。

sansui

熱中症アラートで人がおらん、名駅には沢山いたのに。
暑さを表現しようと散水を撮ってみたけど上手くいかん。

sansui

F22 まで絞ってみたけど 1/60 秒にしかならんし絵も酷い。
レンズがパナなのでライブ ND が。。。

sansui

って帰宅して調べたらライブ ND はパナでも可能なのね。
シャッタースピード優先にしないと使えないだけ、あーあ。

seseri

チャバネセセリとセンニチコウ。
珍しくはない蝶みたいだけど見たことないなぁ。

mukudori

暑くてダルいのかムクドリが寄っても逃げない。
ここまで普通に寄れた、スズメは無理だった。
いや撮るものがないからってムクドリかよって感じ。

しかしパナレンズのせいで OM-1 が活かせないのは。
いや今日のは勘違いだったけど進度合成とかあるし。
少しづつでも Zuiko に入れ替えしたほうがよさげ。

犬山橋

今日の五条川、には何もいねぇ。
アオサギなら何羽かいたけど、いらねぇ。

inuyamabashi

ということで木曽川、犬山橋付近に移動。
昭和の頃は電車と車が並走していた有名な場所。

meitetsu

撮り鉄ごっこ、いや今は電車専用だよという説明用。
てか筆者は並走していた頃を知らん、地元じゃないし。

inuyamajyou

国宝犬山上とコラボ、国宝がおまけ扱いかよ。
オリンパスブルーにならないな、気温のせいか?

aosagi

アオサギ、まあ飛んでいる所なら撮ってもいいかな。
田圃に行けば白いサギがイッパイいると知っているけど。

tsubame

ツバメが取ってくれといわんばかりに鳴いていた。
貴重な夏鳥なのに何故か無視されがちですよね。

kogera

コゲラ、モフモフしているし幼鳥かな。
他シジュウカラやカワウ、まあいつもの木曽川ですね。

地味な名所巡りのブログにするのもいいかも。
でも野鳥がいそうな所にしかいかなそうだなぁ。

キビタキ(幼鳥)

昨年はハスを求めて名古屋市の鶴舞公園まで行ったけど。
よく考えたらハス園なら小牧の某公園にあるじゃないの。

hasu

っておーい、左奥下の所がハス園なのに行けないじゃん。
まあ通路から超望遠で見下ろせばなんとか撮影は可能。

hasu

ということで 280mm F5.6 固定という前回覚えた技で。
こんな綺麗に咲いているのに近くに行けないのはなんでだよ。

hasu

つぼみも巨大な桃みたいでかわいい。
いやこの焦点距離でいい感じの大きさになるのを選んだだけ。

hasu

こんなものかな、近寄れないんだからしょうがない。
さて、この公園に来たらやっぱり野鳥探しですね。

kosamebitaki

セミかと思うほど小さく頭デッカチで白い腹にアイリング。
コサメビタキさんじゃないですか、真夏に初めて見たわ。

kibitaki

何かの幼鳥だと思うけど全然ワカラン、Google レンズに頼る。
キビタキの幼鳥でした、一発で当てたこのアプリやっぱりすげえ。

kibitaki

幼鳥なのに自分で毛虫を捕食し一生懸命生きています。
大人になっても親の脛を齧る奴は生きている価値ないよね。

シーズンオフの真夏なのにいいもの撮れたわ。
しかし今日も超望遠しか使わなかった、他のレンズも使わなきゃ。