Karl Toby Rosenberg

It’s easy too, — on macos and ios. Just hold the key.

Teaching-Visuals-Samples

Crossposting: here’s my mini computer science teaching-suport visuals page containing a bunch of rough sketches, animations, and interactive programs: ktrosenberg.github.io/teaching/

Cite the toolkit paper.

DrawTalking is now open-source!

github.com/KTRosenberg/...

ktrosenberg.github.io/drawtalking/

Unless I missed it, may I suggest that there be a way to freeze/request versions of a model rather than updating to the latest automatically? Otherwise, apps coupled to models’ specific behavior could break at any time. In other words, version control for api stability.

Last thing here: I think it's worth asking "why do students, specifically those who don't want to cheat themselves, reach for an escape hatch anyway when they do?" I know it's sometimes because of overlapping overwhelming schedules and deadlines. This kind of implies an opportunity to intervene.

I'd be interested in talking about these things at-length. SIGCSE is a good community for this too.

I have a kind of blurry thought that we need to create a stronger value proposition. In C.S. it's obvious that just teaching to a language, syntax, etc. is easy to replace. Something goal and project-oriented based on what *students* want feels a bit better. Closed models make experimentation hard.

In principle, I can imagine a totally different AI that aligns with a totally different set of goals, but that's not necessarily an LLM or GPT, and I don't know technically how that'd be created. But I think it would be a useful thought experiment to try to reimagine the ideal again. Just some idea.

Also, there's the human tendency to reach for the path of least resistance, which displaces the potential benefits for learning. I've taught Python for total beginners. What are students learning if they don't understand the fundamentals before prompting for a potentially-erroneous result?

What weirds me out the most is that I see a lot of people claiming that extreme side of the hype. e.g. LLMs can "think" and whatnot. However, for basically everything I want to make, the lack of certain guarantees direct me towards older approaches.

I think that the answer entirely depends on whether you're referring to theoretical gains independent of human nature or not. Honestly, I do wish there could be a discussion of what the HCI design goals and desired behavior of some form of AI should be, putting aside current implementation.

This Game Did Everything. What Happened? YouTube video by Intra

"This Game Did Everything. What Happened?" by Intra (2025)

www.youtube.com/watch?v=AVaj...

You could have both a recently-selected part of the tray and the ability to drag. :) (I can imagine forgetting to drag.)

The most recently-selected object(s) could just go into this tray too. That would save a drag.

If the point is just to move an object to x location off-screen, there’s this tension of not being able to see what the target is, and figuring out when to release. You basically want a precise teleport, but what you get is something like an archery target.

I opened feedback reports for the frame-rate and PointerEvents limitations, although I'm sure the developers are already aware of these.

I’d be curious to read about that 1000hz choice! I imagine you’d need a lot of optimization for anything complicated. I’ve typically followed an old “fixed timestep” tutorial from GafferOnGames.

If wkwebview receives messages as fast as possible (I’d need to test), I guess that doing frame updates on the native side would let you do more frequent “physics” updates at 120hz even if you couldn’t yet perceive the higher framerate.

On the prototyping note, it was really nice when bindless resource support was added to Metal. That enabled theoretically "infinite" textures and buffers without having to worry about swapping-around bindpoints as in the older GPU APIs.

I found the note in the spec saying that yes, vendors can choose to ignore simultaneous touch types: www.w3.org/TR/pointerev...
It's a bit crazy considering native iPad applications handle this just fine. It seems the only solution is to persuade the developers. It's been years though.

This conversation is validating my decision to go native for my project (haha). I didn’t know about these issues at the time and would’ve hit walls. Anyway, it’s awesome that your team is recreating the substance of Sketchpad!
If you’re considering Metal, does that mean you’re using WebGL now?

It depends on whether they enabled higher framerates by default.

Have you tried it revently? bugs.webkit.org/attachment.c...

I have beta 3 on my iPad and can try it later.

Achieving smooth frame rates with Metal’s display link | Apple Developer Documentation Pace rendering with minimal input latency while providing essential information to the operating system for power-efficient rendering, thermal mitigation, and the scheduling of sustainable workloads.

Good point. The compositor's schedule might be all the same anyway. If you use Metal, this is the example with the latest API (since it's a little bit hidden): developer.apple.com/documentatio...

Anyway, if this is true, that just seems crazy. The native API clearly lets you choose how canceling behavior works.

I do think a native wrapper as you have now is good. It lets you call into JS at any native-supported refresh rate without requestAnimationFrame (I think).

True. The best you can get is near-full-screen with a little grey bar at the top (I think).

This is all strangely inconvenient.