Add support for 3D/CAD file formats preview

[kerwin612]

#34775

[wxiaoguang]

I think we need a pure frontend "render plugin" mechanism

1. Register "fronend render plugin"
2. Plugin read page information (for example: file name)
3. If the plugin is able to render it, read the "raw" content, then replace the "fileview" element.

I don't think we should hard-code too many file types in backend.

[wxiaoguang]

IIRC it bloats the binary about 1MB

Can we introduce an config option?

For example:

• RENDER_PLUGIN_ONLINE_3D_VIEWER = https://public-js-cdn/....

[kerwin612]

From a user's perspective, I personally feel that direct integration is better than dynamic loading.
Because building and installation are one-time processes.
However, if we switch to dynamic loading, each time it might require dynamically loading 1MB of JavaScript.
Especially in the current Chinese network environment, sometimes even some external CDNs cannot be accessed, which would directly make the preview unavailable.

So I personally vote for integration.
Of course, the final decision is up to you.

[wxiaoguang]

However, if we switch to dynamic loading, each time it might require dynamically loading 1MB of JavaScript.

Not "each", only once, there is browser cahce.

Especially in the current Chinese network environment, sometimes even some external CDNs cannot be accessed, which would directly make the preview unavailable.

That's why a config option to let users choose, or deploy one locally.

---

If we build the renders into Gitea's binary, then it bloats the binary soon when we introduce more in the future.

[kerwin612]

I fully understand your original intention, but I think this still stems from the perspective of operators. From a user's point of view, such an option shouldn't exist (or there's simply no need for it at all) – the default provided to users should inherently be the optimal solution.

Of course, I recognize that Gitea, as an open-source platform, does have many "operator" users. Your original intention might be to allow them to choose freely, but personally, I wonder if such customization is getting too caught up in minor details?

Alright, I've shared my thoughts. It's up to you all. If adjustments are needed, I'll cooperate with the changes.

[wxiaoguang]

Share some of my thoughts:

There are different requirements for various kinds of files to render.

• Some are widely-used, for example: CSV, PDF, etc
• Some are only used by some of the users: asciidoc, asciicast, console, 3d models, etc. The percentage varies.

So the question is how to make Gitea have a stable and flexible design to satisfy more renders in the future. Then we have some choices:

1. Only make widely-used renders builtin, keep the release binary as small as possible.
2. Make all renders builtin, then we should have some estimation about the side effects, and how large the binary would be in the future.

I haven't got a clear picture of this feature at the moment. What do other maintainers think about?

[wxiaoguang]

No

[hiifong]

I think the memory hog is more the git command.

[wxiaoguang]

I think the memory hog is more the git command.

I don't understand what's the point or whether it is related to the topic.

[TheFox0x7]

That's a separate issue though and there's not much that can be done to limit it. Also it's (IMO) a very large issue for limited memory scenarios which is entirely of topic here.

I can't say I know a ton about this, but here point is that if you bloat the binary it had to be loaded and run each time hook runs which is a waste of resources - hope I got that right.
Honestly hook doesn't even have to have inits(not too sure about it though?) - it just needs to know where gitea is to do RPC.

---

Sorry for derailing the scope.

[wxiaoguang]

Honestly hook doesn't even have to have inits(not too sure about it though?)

In history, the "gitea hook" sub commands always do various init calls (including load assets), for example: var re = regexp.MustCompile, init() { ... }, etc

When I refactor existing code, usually I also rewrite these code to something like sync.OnceValue and void unnecessary init.

About the binary size affect, it's more complicated and it depends on some OS behaviors like virtual memory/mmap management, usually the binary content should be cached in OS's shared-memory area when it runs, but it's difficult to evaluate all cases (especially when the memory is limited in a container), I am not expert either so it's just a guess.

So I also agree that "if increasing the binary size brings enough benefits, let's do it", and I think "It's fine to make this render builtin".